This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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:

[...]

| > | 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.:


    struct S {
       double data[2];
       S() : data()             // #1
       { }
    };

At line #1, we have value-initialization. Are you disagreeing with that?

No, rather, I had forgotten that was permitted.


I don't think that alters my opinions about the rest of the situation, though; in particular, I'd prefer to see _Complex be considered a scalar and be implicitly convertible to/from other types as per C99.

In any case, it certainly doesn't change my lack of interest in working further on this PR. I'm just not that motivated. When there's a clear consensus, great; until then I'm going to work on other areas where I can be more productive.

--
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]