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