This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Problems with PR 21210
Gabriel Dos Reis wrote:
Yes, I do fully agree on that. What I'm suggesting is that an int is
convertible to a __complex__ T, but the conversion must be requested
explicilty; just like T* -> int exists but must be written explicitly.
Well, that's not compatible with C99 or pre-4.0 G++. Maybe that's OK.
Certainly, if there's no standard conversion from "int" to "__complex__
double", then the problem goes away. I think that would be another
technically feasible, but undesirable, solution. But, it's been
well-established that you and I have very different value systems.
| Jason's approach is better; treat it as a built-in, but make
| conversions to it worse than ordinary floating-point types. I think
| that's somewhat odd, but much less so than making "fcomplex()" result
| in anything other than complex zero.
Once again, you're mischaracterizing what I said. From what I said is
fcomplex() would be value-intialization, and since it would be
treated as an array of two elements, fcomplex() boils down to
value-initialization of its components, and in this case
zero-initialization of the components. Henc fcomplex() is zero. QED.
You can't initialize an array at present in this way, e.g.:
typedef int IA[2];
void f() {
IA(); // Invalid
}
I think that what you're really doing is reinventing Nathan Myers' idea,
but making _Complex a separate type from std::complex. You're saying
that it's like an aggregate, not a scalar, but has overloaded operators
(like "+"), that it permits explicit conversions from integers, but not
implicit ones (as if it had an "explicit" constructor), and that it can
be constructed with "fcomplex()" (as if it had a default constructor),
but that this is not zero-initialization. I think that you're thinking
of _Complex as a built-in clas. Again, in my opinion, technically
viable, but not desirable.
I just wanted to fix a PR that affected 4.0. I thought (and even still
think) that there is a relatively simple solution. But, I also think
that this is now going to be a long discussion about a lot of other
isssues, with relatively low likelihood of a quick resolution. I hope
that the committee will resolve all of these issues, and then we can
implement whatever it is that they decide. Until then, I'm going to
unassign myself from the PR, and go on to other issues.
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304