This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]