This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: Problems with PR 21210


Mark Mitchell <mark@codesourcery.com> writes:

| 
| Removing the extra libstdc++ constructor is not ideal, because then
| __complex__ double can still be converted to complex<double> -- but
| the conversion happens via the implicit conversion from __complex__
| double to double, so the imaginary part of the value is lost.


I think I know why I put that constructor there (obvisouly, it appears
now to be careless).  It was an easy and cheap way to construct
comple<T> objects on the fly from __complex__ types, back in the dark
ages where GCC was unable to optimize away "temporary objects in the
middle that appear to live in memory".  I believe the right thing to
do is to remove it, predicated on the fact that the two arguments
constructor is inline and fairly trivial so that 


  template<class T>
   inline complex<T> 
   make_std_complex(T __complex__ z)
   {
      return complex<T>(__real__ z, __imag__ z);
   }

has zero abstraction penalty.  

I'm very reluctant to additions of constructors.

-- Gaby


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