Problems with PR 21210

Gabriel Dos Reis gdr@integrable-solutions.net
Mon May 30 15:37:00 GMT 2005


Chris Jefferson <caj@cs.york.ac.uk> writes:

| Mark Mitchell wrote:
| > Gabriel Dos Reis wrote:
| > 
| >> Mark Mitchell <mark@codesourcery.com> writes:
| > 
| > 
| >>   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.
| > 
| > 
| > That's OK with me -- if you're willing to accept the fact that this will
| > silently change the meaning of:
| > 
| >   __complex__ double c99_cd;
| >   complex<double> cpp_cd(c99_cd);
| > 
| > I just want to make sure that you're aware that what you're suggesting
| > will change that; it will now simply copy the real part, and ignore the
| > imaginary part.
| > 
| 
| I suspect I won't be the only person to say this, but if this change is
| made it should be documented VERY, VERY CLEARLY. I have personally
| worked on code where both __complex__ double and complex<double> and the
| exact above notation was moved to convert one to the other, and I'm sure
| I'm not the only person (in particular because it was believed, I
| believe not entirely without reason, that __complex__ was move efficent).

I can tell you the reason why I choosed to use __complex__: I wanted
to benefit from complex functions wherever implemented by the target
system and object layout compatibitlity.  Whether it was move
efficient at the time was not even considered.

I'm going to raise this issue in the LWG as there have been several
iterated proposals to enhance compability with C99 and this issue was
not considered, and clearly this is not just with libstdc++.

-- Gaby



More information about the Libstdc++ mailing list