std::complex standard packing requirements was Re: [eigen] FFT for Eigen |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: std::complex standard packing requirements was Re: [eigen] FFT for Eigen*From*: Mark Borgerding <mark@xxxxxxxxxxxxxx>*Date*: Tue, 19 May 2009 17:43:57 -0400

I had this discussion a few years ago on comp.lang.c++ when I was
trying to share complex buffers between c99 libs and C++ apps. The bottom line is that the original C++ ISO standard did not require array[2] packing for std::complex, but that requirement was in the standards pipeline and all sane compilers already do it. http://www.cpptalk.net/portable-complex-numbers-between-c-c--vt46432.html http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387 It should be safe enough to go down that path, but it would still be good to add a compile time check to ensure sizeof( std::complex<T> ) == 2*sizeof(T) and a runtime check for &cpx.imag() - &cpx.real() == 1 -- Mark Benoit Jacob wrote: I'm OK if this doesn't crash. If the STL clearly specifies that the two coords in a complex<> are stored as an array, then it's OK. If on the other hand, some implementation stores the 2 coordinates as just 2 separate members, and someone compiles this with a strict 64 bit alignment, then with complex<float> that will crash. Benoit 2009/5/19 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:Really? The only real() that I can see is const, and anyway, how would we implement that? std::real() and std::imag() only return references with certain GCC implementations while e.g. on GCC 4.0 / Mac they return by value. It seemed to me that allowing that was one of the things that would require us to have our own complex numbers class.arf, you are right., one more stupid annoying std limitation....ok, so, is anyone against adding that: inline float& ei_real(std::complex<float>& x) { return reinterpret_cast<float*>(&x)[0]; } inline float& ei_imag(std::complex<float>& x) { return reinterpret_cast<float*>(&x)[1]; } so that we can have real() returning a lvalue ? Gael. |

**Follow-Ups**:**Re: std::complex standard packing requirements was Re: [eigen] FFT for Eigen***From:*Benoit Jacob

**References**:**[eigen] FFT for Eigen***From:*Mark Borgerding

**Re: [eigen] FFT for Eigen***From:*Benoit Jacob

**Re: [eigen] FFT for Eigen***From:*Rohit Garg

**Re: [eigen] FFT for Eigen***From:*Benoit Jacob

**Re: [eigen] FFT for Eigen***From:*Gael Guennebaud

**Re: [eigen] FFT for Eigen***From:*Ricard Marxer Piñón

**Re: [eigen] FFT for Eigen***From:*Gael Guennebaud

**Re: [eigen] FFT for Eigen***From:*Benoit Jacob

**Re: [eigen] FFT for Eigen***From:*Gael Guennebaud

**Re: [eigen] FFT for Eigen***From:*Gael Guennebaud

**Re: [eigen] FFT for Eigen***From:*Benoit Jacob

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] FFT for Eigen** - Next by Date:
**Re: std::complex standard packing requirements was Re: [eigen] FFT for Eigen** - Previous by thread:
**Re: This topic is complex number portability, not Re: [eigen] FFT for Eigen** - Next by thread:
**Re: std::complex standard packing requirements was Re: [eigen] FFT for Eigen**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |