C++ support for decimal floating point
Gabriel Dos Reis
dosreis@gmail.com
Thu Sep 24 03:09:00 GMT 2009
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
>
More information about the Libstdc++
mailing list