C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Layout of complex<T>          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Glen Low Guest Posted: Wed Jul 28, 2004 3:14 am    Post subject: Layout of complex<T> Hi all, I'm in the process of optimizing valarray <complex using Altivec for my library macstl, and mildly stymied by the rather liberal requirements for complex <T> layout in the Standard: 26.2.2/1 -- The class complex describes an object that can store the Cartesian components, real() and imag(), of a complex number. Now C99 has a more strict definition 6.2.5/13 -- Each complex type has the same representation and alignment requirements as an array type containing exactly two elements of the corresponding real type; the first element is equal to the real part, and the second element to the imaginary part, of the complex number. It seems David Abrahams and friends proposed a more predictable layout for such non-POD types as complex<T> back in 2002: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1356.html Qn: what has happened to the proposal? Side qn(s): what does the Standard say about sizeof (T) and sizeof (U) for the following: 1. T is an inbuilt type and U is a non-POD (with no virtuals) whose sole data member is of type T? 2. T is an array of an inbuilt type and U is a non-POD (with no virtuals) whose sole data member is of type T? (I kind of expect the Standard says nothing about sizeof(T) and sizeof (U), but that in practise they are equal...) Cheers, Glen Low, Pixelglow Software www.pixelglow.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Bill Wade Guest Posted: Thu Jul 29, 2004 3:20 pm    Post subject: Re: Layout of complex<T> [email]glenlow (AT) pixelglow (DOT) com[/email] (Glen Low) wrote in message news:<9215d7ac.0407271826.138df83 (AT) posting (DOT) google.com>... Quote: Side qn(s): what does the Standard say about sizeof (T) and sizeof (U) for the following: 1. T is an inbuilt type and U is a non-POD (with no virtuals) whose sole data member is of type T? 2. T is an array of an inbuilt type and U is a non-POD (with no virtuals) whose sole data member is of type T? (I kind of expect the Standard says nothing about sizeof(T) and sizeof (U), but that in practise they are equal...) You're pretty close if 1) your definition of "inbuilt" corresponds to the standard's "fundamental" types (floating point, integer, char, bool). 2) U has no base classes. 3) The data member is non-static. I expect that there are C++ implementations where all structs have a size that is a multiple of 2 (or some other "large" number), and it is not uncommon for compilers to provide this as an option. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Glen Low Guest Posted: Fri Jul 30, 2004 4:02 pm    Post subject: Re: Layout of complex<T> Quote: You're pretty close if 1) your definition of "inbuilt" corresponds to the standard's "fundamental" types (floating point, integer, char, bool). 2) U has no base classes. 3) The data member is non-static. The "vendor-neutral" C++ ABI, or the ABI Formely Known as the Itanium C++ ABI, seems to say this. http://www.codesourcery.com/cxx-abi/ However I can't seem to nail down how much tail padding the struct/class would get, which would affect the sizeof values. What's the general opinion on this C++ ABI; how well is it supported and are there any moves at all to make this a standard of sorts? Cheers, Glen Low, Pixelglow Software www.pixelglow.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Gabriel Dos Reis Guest Posted: Sun Aug 01, 2004 2:12 am    Post subject: Re: Layout of complex<T> [email]glenlow (AT) pixelglow (DOT) com[/email] (Glen Low) writes: Quote: Hi all, I'm in the process of optimizing valarray <complex using Altivec for my library macstl, and mildly stymied by the rather liberal requirements for complex <T> layout in the Standard: 26.2.2/1 -- The class complex describes an object that can store the Cartesian components, real() and imag(), of a complex number. Now C99 has a more strict definition 6.2.5/13 -- Each complex type has the same representation and alignment requirements as an array type containing exactly two elements of the corresponding real type; the first element is equal to the real part, and the second element to the imaginary part, of the complex number. Have a look at Library Issue #387 and http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2002/n1388.pdf -- Gabriel Dos Reis [email]gdr (AT) integrable-solutions (DOT) net[/email] [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Glen Low Guest Posted: Mon Aug 02, 2004 10:25 am    Post subject: Re: Layout of complex<T> Quote: Have a look at Library Issue #387 and http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2002/n1388.pdf Interesting. The rationale says: The LWG believes that C99 compatibility would be enough justification for this change even without other considerations. All existing implementations already have the layout proposed here. Just a straw poll, then: does your favorite C++ standard library implementation implement complex <T> like an array of 2 T's, where the first T is the real part and the second T is the imaginary part? Are the valarray and complex headers separate or do they include each other? I'm particularly interested in gcc, XLC++, Metrowerks, Visual C++. On the other hand, I don't agree with the other thrust of n1388.pdf where you've said valarray::operator[] const should return a const T& (reference) instead of a T (value). I've taken this to another discussion thread, but I find this proposal rather strange since you're responsible for the only other expression template implementation of valarray I can find. Cheers, Glen Low, Pixelglow Software www.pixelglow.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Gabriel Dos Reis Guest Posted: Mon Aug 02, 2004 2:35 pm    Post subject: Re: Layout of complex<T> [email]glenlow (AT) pixelglow (DOT) com[/email] (Glen Low) writes: Quote: Have a look at Library Issue #387 and http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2002/n1388.pdf Interesting. The rationale says: The LWG believes that C99 compatibility would be enough justification for this change even without other considerations. All existing implementations already have the layout proposed here. Just a straw poll, then: does your favorite C++ standard library implementation implement complex <T> like an array of 2 T's, where the first T is the real part and the second T is the imaginary part? Are the valarray and complex headers separate or do they include each other? I'm particularly interested in gcc, XLC++, Metrowerks, Visual C++. My favorite compiler is GCC, and yes it lays out std::complex<> as reported in the paper. It does not have <complex> or <valarray> include each other Why are you asking for the latter? Quote: On the other hand, I don't agree with the other thrust of n1388.pdf where you've said valarray::operator[] const should return a const T& (reference) instead of a T (value). I've taken this to another discussion thread, See my follow-up to your message. Quote: but I find this proposal rather strange since It is based on actual confrontation with real world uses, and requests. Quote: you're responsible for the only other expression template implementation of valarray I can find. I believe there are two things that were confused when the valarray component was specified: The concept of array expression and a concrete incarnation through the class template std::valarray<T>. The concrete class std::valarray<T> should have subscription return a reference; however, it suffices that for other array expressions, individual subscription returns something convertible to const T&. That does not preclude expression template implementation of valarray. HTH, -- Gabriel Dos Reis [email]gdr (AT) integrable-solutions (DOT) net[/email] [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top P.J. Plauger Guest Posted: Mon Aug 02, 2004 2:41 pm    Post subject: Re: Layout of complex<T> "Glen Low" <glenlow (AT) pixelglow (DOT) com> wrote Quote: Have a look at Library Issue #387 and http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2002/n1388.pdf Interesting. The rationale says: The LWG believes that C99 compatibility would be enough justification for this change even without other considerations. All existing implementations already have the layout proposed here. Just a straw poll, then: does your favorite C++ standard library implementation implement complex <T> like an array of 2 T's, where the first T is the real part and the second T is the imaginary part? It's also okay to use a struct with two T members, if there's no added padding. You then luck out and get a layout compatible with an array of two T. We use an array of two T within a struct, for a host of language reasons, and that seems to work fine on all the (many) platforms we've ported our C and C++ libraries to. Quote: Are the valarray and complex headers separate or do they include each other? Dunno why that should be a requirement. Quote: I'm particularly interested in gcc, XLC++, Metrowerks, Visual C++. gcc is a compiler. The C library that works with it is often glibc, and sometimes ours. The C++ library that ships with it is libstdc++, but sometimes people use STLport or ours. Visual C++ uses the Microsoft C library and our C++ library. P.J. Plauger Dinkumware, Ltd. http://www.dinkumware.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Glen Low Guest Posted: Tue Aug 03, 2004 11:30 am    Post subject: Re: Layout of complex<T> Quote: Just a straw poll, then: does your favorite C++ standard library implementation implement complex <T> like an array of 2 T's, where the first T is the real part and the second T is the imaginary part? It's also okay to use a struct with two T members, if there's no added padding. You then luck out and get a layout compatible with an array of two T. We use an array of two T within a struct, for a host of language reasons, and that seems to work fine on all the (many) platforms we've ported our C and C++ libraries to. I just had a peek at libstdc++ and it uses a struct with two T members, which would fail to comply when sizeof(T) < the usual alignment. Thus the somewhat degenerate cases of complex complex <short> might not comply on a 32-bit aligned compiler. Quote: Are the valarray and complex headers separate or do they include each other? Dunno why that should be a requirement. My library macstl has a valarray implementation that is optimized using Altivec, but I currently put it in namespace std. I suppose the "right thing" to do is to put it in its own namespace so that it can co-exist with the hosted Standard Library. Otherwise, I'd hope that no other header else inadvertently includes the hosted valarray and causes an ODR violation. Quote: I'm particularly interested in gcc, XLC++, Metrowerks, Visual C++. gcc is a compiler. The C library that works with it is often glibc, and sometimes ours. The C++ library that ships with it is libstdc++, but sometimes people use STLport or ours. Visual C++ uses the Microsoft C library and our C++ library. Cool. Cheers, Glen Low, Pixelglow Software www.pixelglow.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Gabriel Dos Reis Guest Posted: Wed Aug 04, 2004 10:11 am    Post subject: Re: Layout of complex<T> [email]glenlow (AT) pixelglow (DOT) com[/email] (Glen Low) writes: Quote: Just a straw poll, then: does your favorite C++ standard library implementation implement complex <T> like an array of 2 T's, where the first T is the real part and the second T is the imaginary part? It's also okay to use a struct with two T members, if there's no added padding. You then luck out and get a layout compatible with an array of two T. We use an array of two T within a struct, for a host of language reasons, and that seems to work fine on all the (many) platforms we've ported our C and C++ libraries to. I just had a peek at libstdc++ and it uses a struct with two T members, which would fail to comply when sizeof(T) < the usual alignment. Thus the somewhat degenerate cases of complex complex <short> might not comply on a 32-bit aligned compiler. If you instantiate std::complex<> with char or short, you have bigger issues to worry about than hypothetical architectures, on which the compiler supposely would not behave properly because of unusual alignment. Quote: Are the valarray and complex headers separate or do they include each other? Dunno why that should be a requirement. My library macstl has a valarray implementation that is optimized using Altivec, but I currently put it in namespace std. I suppose the "right thing" to do is to put it in its own namespace so that it can co-exist with the hosted Standard Library. That strikes me as the obvious thing to do. -- Gabriel Dos Reis [email]gdr (AT) integrable-solutions (DOT) net[/email] [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.