This is the mail archive of the 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

Benjamin Kosnik wrote:
or that it leaves other problems open in general, with respect to C99 complex vs. C++ complex?

You're solving this issue just for std::complex. Admittedly the problem domain may be small for this issue (although I suspect scientific computing types would disagree). A solution may be useful for more than just std::complex.

I *am* a scientific computing type. :-)

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);

  double d;
  ... f(d) ...

which f should get called? Under the semantics I used (conversion from double to __complex__ double is a standard conversion) we'd pick the second "f". I'd say either we should use the second "f", which seems right to me; the other plausible choice would be to consider the call ambiguous.

2. Should we have overloads of "sin" (and so forth) for "__complex__" types?

But, those other questions seem outside the scope of the original PR (which is about a core language problem) although clearly within the scope of the general question "how do we integrate C99's complex types into C++?"

The problem I'm faciing is that the PR is about a core language (not library) problem; however, the obvious core language fix breaks the library. I'm hoping Gaby's going to ride up on a white horse with some kind of consensus of C++ standards committee people...

What happens if other C99 or C0x types are added (ie ucs2 integer
type)? I think figuring out a way to deal with this now in the general
case is probably a better idea.

I don't think we can come up with a general method. Each C99/C0X type is going to interact differently with different parts of the language and the standard library.

I agree that the constructor thing is a hack. But, if Gaby's horse doesn't make it, I think it should be considered seriously, in view of the fact that the other good suggestion is a change to the core overload resolution rules, which is rather more irreversible. In other words, the constructors in the library would be at worst redundant, but could be safely left in forevermore; the core language change might result in incompatible changes to G++ in future.

Mark Mitchell
CodeSourcery, LLC
(916) 791-8304

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