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


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


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