This is the mail archive of the 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:

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
(916) 791-8304

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