This is the mail archive of the
mailing list for the GCC project.
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(__complex__ double);
... 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
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
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.