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:
Mark Mitchell <mark@codesourcery.com> writes:
| Gabriel Dos Reis wrote:
| > Mark Mitchell <mark@codesourcery.com> writes:
| > | PR 21210 is a complaint that G++ 4.0 has stopped allowing
| > conversions
| > | from integers to "__complex__ float". This is a perfectly reasonable
| > My reading of the PR is a bit different, especially comment #1
| > typedef float __complex__ fcomplex;
| > fcomplex cplx = fcomplex();
| > which effectively produces the error
| > 21210.C:2: error: invalid cast from type 'int' to type 'float
| > __complex__'
| > which is at least disturbing, because there is not cast and no int
| > here. Rather, there is a default value fcomplex() being requested and
| > copied into another fcomplex. There is no conversion requested. That
| > appears to me to be entirely isolated from the std::complex<> thingy.
| > Why is that observation flawed?
|
| Because the "T()" syntax means zero-initialization for builtin
| types. You will get the same error message if you write "fcomplex(3)".
Aha, I see. Thanks. But would not that be separate from the
std::complex<> issue you raised earlier?
No.
The problem is that we have to say how integers convert to __complex_
types. If it's a standard conversion, then without changing the
overloading rules, conversion from "int" to "double" or to "__complex__
double" is equally good. So, the std::complex constructors are ambiguous.
However, if we treat fcomplex() as value-initialization -- because it
is more like an array of two floats, than a float -- then we will be
value-initializing its components and that would be OK. Do you agree?
I think that would be wrong. The fact that a __complex__ types happens
to have "real" and "imag" operators doesn't make it any less a scalar
type to me. In other words, I think what you're proposing is
technically feasible, but not a good design. The fact that it's not a
compound type in C99 is evidence that we should treat it like any other
built-in type in C++.
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.
But, the issue of writing fcomplex(3) is still open. I think such
conversion must be allowed only if written explicitly -- i.e. explicit
conversion.
That's at odds with C99, and at odds with ncm's
__complex__-is-the-same-type-as-std::complex idea.
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304