Re: [eigen] FFT for Eigen

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


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.
>
>
>



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