Problems with PR 21210
Mark Mitchell
mark@codesourcery.com
Wed Jun 1 03:09:00 GMT 2005
Nathan (Jasper) Myers wrote:
> On Tue, May 31, 2005 at 03:20:29PM -0700, Mark Mitchell wrote:
>
>>I'm not sure what other areas of concern arise, with respect to this PR,
>>which is just about the core language.
>>
>>There are indeed other questions, though, like:
>>
>>1. Overload resolution
>>
>> void f(std::complex<double>);
>> void f(__complex__ double);
>>
>>2. Should we have overloads of "sin" (and so forth) for "__complex__"
>> types?
>
>
> 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. 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.
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?
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304
More information about the Libstdc++
mailing list