Re: Problems with PR 21210

["Nathan (Jasper) Myers" <ncm at codesourcery dot com>]

On Tue, May 31, 2005 at 08:09:37PM -0700, Mark Mitchell wrote:
> Nathan (Jasper) Myers wrote:
> >On Tue, May 31, 2005 at 03:20:29PM -0700, Mark Mitchell wrote:
> >
> >The Intent of the Committee was that compilers would open-code complex 
> >and val_array objects if there was anything to be gained by it.   
> >That is, std::complex<> and __complex__ ought to one and the same 
> >type.   I hope the C committee has not given them such different 
> >semantics that it's impossible.
> 
> (From now on, I'm going to call __complex__ by its official C99 name, 
> which is _Complex.)
> 
> Every libstdc++ std::complex<> presently contains a _Complex, so making 
> them the same type would break that.  But, yes, it would be cool if they 
> were magically the same type.
> 
> Under this interpretation, would you have to #include <complex> before 
> you got to use _Complex?  (That's not true in C99.)

Of course not.

>  But, if _Complex in 
> C++ is going to be the same type as std::complex, then it seems like 
> you'd have to have the header to make everything make sense.

The header just exposes the alternative name, std::complex<float>
(or std::complex<double>) for the same type, which is implicitly fully
defined.  The syntax that establishes the identity must be a local 
extension, but that's OK: the headers already contain plenty of that.

> Or do you mean that there should be a magic rule that declares 
> _Complex and std::complex compatible types, even though they're 
> spelled differently?

That's allowed.  From an engineering standpoint it is probably better 
for the header to assert something.  (This isn't so different from what
is done with memcpy and (lately) NULL.)  Then, in code that appears in 
a compilation unit before the <complex> header is included, any mention 
of std::complex<> is undefined, but you can still declare functions 
that take _Complex, because that's a built-in type.  After the header 
is included, you can create std::complex<> values that match exactly.

Of course all this depends on the C committee not to have maliciously
or negligently made _Complex semantics too different from std::complex<>.
I can imagine that promotion rules double->_Complex must be different
from double->std::complex<>, because we can't program arithmetic 
conversions to normal class types.  If they didn't leave wiggle room 
-- i.e. double->_Complex is allowed _not_ to be an arithmetic promotion 
-- we might be screwed.  However, since this is C++, and "as close as 
possible to C99, but no closer", maybe not.  After all, C doesn't have
overloading rules.

This also depends on somebody not myself doing a not-insubstantial
amount of core compiler work to make it happen; and somebody else
jimmying the libstdc++ headers to match, presumably a lesser task.

Nathan Myers
ncm@cantrip.org