Re: [eigen] FFT for Eigen

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

So unless this turns out to be safe, I'd rather add that to our list
of excuses for adding our own complex class (in addition to continued
support for std::complex).

Benoit

2009/5/19 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> 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.
>>
>>
>>
>