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

Paolo Carlini wrote:
Mark Mitchell wrote:

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.

I must be missing something, either technical about the language itself
or about the present discussion: I don't see how would be correct
picking the second 'f'; ambiguity seems also wrong. My reasoning is
that, according to the current C++ standard, we have a constructor from
a pair of doubles, each one *with a default*: the first f, by itself
certainly works. Then, we add a *non-standard* constructor, from
__complex__ double, and... boomer! it gets *preferred*!?! Please explain
in better detail.

We're not talking about which constructors for std::complex is used anymore; we're talking about which "f" you call. (We left the standard behind when we declared the second "f"; this is no longer an ISO C++ program.)

The same puzzle would apply even if you had a library where std::complex didn't have a constructor from "__complex__". In other words, just think about the question I asked like this:

  struct S {

  void f(S);
  void f(__complex__ double);

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

Which "f" should we call?

The conversion to "S" requires a constructor call, which is usually considered worse than a "standard conversion" (like converting from "int" to "double"). So, that's why I think we should call the second "f".

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]