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

[Mark Borgerding <mark@xxxxxxxxxxxxxx>]

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.