This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Problems with PR 21210
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: mark at codesourcery dot com
- Cc: libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, jason at redhat dot com, nathan at codesourcery dot com, ncm at codesourcery dot com
- Date: 29 May 2005 23:56:53 +0200
- Subject: Re: Problems with PR 21210
- References: <200505292006.j4TK6ktK008048@sethra.codesourcery.com>
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