This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Problems with PR 21210
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Paolo Carlini <pcarlini at suse dot de>
- Cc: Benjamin Kosnik <bkoz at redhat dot com>, gdr at integrable-solutions dot net, jason at redhat dot com, libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, nathan at codesourcery dot com, ncm at codesourcery dot com
- Date: Tue, 31 May 2005 17:15:41 -0700
- Subject: Re: Problems with PR 21210
- References: <200505292006.j4TK6ktK008048@sethra.codesourcery.com> <xyphdgkpc53.fsf@miranda.boston.redhat.com> <429B9AAF.30509@codesourcery.com> <m34qckfc3j.fsf@uniton.integrable-solutions.net> <429BBDDE.10301@codesourcery.com> <20050531170242.6a3d8f55.bkoz@redhat.com> <429CE32D.3060801@codesourcery.com> <429CE6B4.5010505@suse.de> <429CE7F8.8000808@codesourcery.com> <429CFA8C.4080606@suse.de>
Paolo Carlini wrote:
Mark Mitchell wrote:
The conversion to "S" requires a constructor call, which is usually
considered worse than a "standard conversion" (like converting from
"int" to "double"). So, that's why I think we should call the second "f".
Well, you carefully avoided to tell me, but currently we *are* calling
the *first* "f"... ;)
That's true. That's because, at present, we don't allow any implicit
conversions to/from __complex__ types, at variance with C99.
This doesn't mean I'm not seeing your point of course, but maybe we
don't really want to have the "right" overloading *now*, when things are
still up in the air about C++ vs C99...
Sure, we could just wait until this is completely solved in the
committee. (In fact, we could even turn off __complex__ in C++ until
then. I'd be OK with that, but it would break more things for people
who are using __complex__, including V3.)
this context, Jason proposal seems naively right to me, in the sense
that seems to me "conservative": given the *current* standard how
possibly an extension like __complex__ can be preferred to a builtin type?
I'm confused; I don't think any proposal is preferring __complex__ to a
builtin type. My proposal made a conversion from "int" to "__complex__"
equivalent to a conversion from "int" to "double" -- but not better.
But, I do think Jason's proposal is technically viable, even if it's not
my first choice.
More generally, if Jason proposal is considered too risky a choice from
the point of view of the future evolution of C++, I would suggest to
stay as close as possible to the behavior of 3.4.x. To my best
knowledge, not many people complained. I would venture to say, no-one
complained about the behavior of vector<__complex__> and
std::complex(__complex__)...
I agree with the spirit of what you're saying, but I'm not sure I know
how to achieve it in our current codebase. But, I also haven't looked
at exactly what 3.4.4 did very closely, and I don't really know if it
makes sense. If there's no consensus about how to move forward, we can
look further into just trying to be bug-compatible with 3.4.4.
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304