Re: C++ support for decimal floating point

[Gabriel Dos Reis <dosreis at gmail dot com>]

On Wed, Sep 23, 2009 at 9:19 PM, Benjamin Kosnik <bkoz@redhat.com> wrote:
>
>> >> Could you expand on why std::complex<> is not interoperable with
>> >> GCC's complex extension. ?The reason is that I would like to know
>> >> better where the incompatibilities come from -- I've tried to
>> >> remove any.
>
> Also interested in this. It was my understanding that GNU and
> Dinkumware libs were interoperable with C99 Complex.
>
> Just a side note, make sure to follow the specializations, not the
> primary template for std::complex. It's easy to get confused.
>
>> > I was just repeating what I had heard from C++ experts. ?On
>> > powerpc-linux they are currently passed and mangled differently.
>
> Why? Do you know if this is powerpc-specific (and if so, what other
> arches might also have this issue?)
>
>> I've been careful not to define a copy constructor or a destructor
>> for the specializations of std::complex<T> so that they get treated
>> as PODs, with the hope that the compiler will do the right thing. ?At
>> least on my x86-64 box
>> ?running openSUSE, I don't see a difference. ?I've also left the
>> copy-n-assignment operator at the discretion of the compiler
>>
>> ? ? ? // The compiler knows how to do this efficiently
>> ? ? ? // complex& operator=(const complex&);
>
> Situation on trunk shows std::complex<double> is standard layout, but
> not POD.
>
> ie:
>
> ?template<>
> ? ?struct complex<double>
> ? ?{
> ? ? ?typedef double value_type;
> ? ? ?typedef __complex__ double _ComplexT;
>
> ? ? ?complex(_ComplexT __z) : _M_value(__z) { }
>
> ? ? ?complex(double __r = 0.0, double __i = 0.0)
> ? ? ?{
> ? ? ? ?__real__ _M_value = __r;
> ? ? ? ?__imag__ _M_value = __i;
> ? ? ?}
>
> ? ? ?complex(const complex<float>& __z)
> ? ? ?: _M_value(__z.__rep()) { }
>
> ? ? ?explicit complex(const complex<long double>&);
>
> ?...
>
> ? ?private:
> ? ? ?_ComplexT _M_value;
> ? ?};
>
> There are existing problems with these ctor overloads in the presence of
> initialization lists I believe.

sorry: I should have been more precise.  I meant "POD for parameter
passing purposes",
e.g.

   http://www.codesourcery.com/public/cxx-abi/abi.html#normal-call

we don't have any non-trivial copy-constructor or destructor.

>
> -benjamin
>