This is the mail archive of the gcc-patches@gcc.gnu.org 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


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


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