This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: C++ support for decimal floating point
> >> 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.
-benjamin