This is the mail archive of the
mailing list for the GCC project.
Re: Problems with PR 21210
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, jason at redhat dot com, nathan at codesourcery dot com, ncm at codesourcery dot com
- Date: 01 Jun 2005 09:27:39 +0200
- Subject: Re: Problems with PR 21210
- References: <200505292006.j4TK6ktK008048@sethra.codesourcery.com><firstname.lastname@example.org><429D4BE5.email@example.com>
Mark Mitchell <firstname.lastname@example.org> writes:
| Gabriel Dos Reis wrote:
| > Mark Mitchell <email@example.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?
If we want to treat __complex__ in C++ as a built-in, then we cannot
have it both working as C99 and working as C++ std::complex<T> because
of incompatible requirements.
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?
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 removes the ambiguity one might run into with
std::complex<>. It isn't fully compatible with C99, but we just
demonstrated that we cannot have full compatibility with C99 in this