This is the mail archive of the
mailing list for the GCC project.
Re: C++ PATCH: PR 20599 (1/3)
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Cc: Douglas Gregor <doug dot gregor at gmail dot com>, gcc-patches at gcc dot gnu dot org, libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: Sun, 01 Oct 2006 14:04:03 -0700
- Subject: Re: C++ PATCH: PR 20599 (1/3)
- References: <450A658C.firstname.lastname@example.org> <450F024C.email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <20060919173834.GR31210@synopsys.com> <firstname.lastname@example.org> <email@example.com> <4511B690.firstname.lastname@example.org> <4516CCFB.email@example.com> <0535BDD0-FEEB-4C4D-823D-2EC7FC9BC2B6@osl.iu.edu> <firstname.lastname@example.org>
Benjamin Kosnik wrote:
* Therefore, building on the suggestions in this thread, my
suggestion is that we:
(a) add C++0x features only with a command-line option (off by
default, for now) so that users have to explicitly request the
(b) document that option in the manual as enabling experimental
features and warning people that C++0x is subject to change, and
that the GCC Gimplementation will track the actual standard,
without regard for backwards compatibility with previous GCC releases,
(c) refrain from adding a feature until it is actually part of the
WP, so that "feature oscillation" is minimized.
I think these points are a good start, but can be improved.
Specifically, I think some kind of predefined macro when the flag is
enabled is mandatory. I believe others have suggested this as well.
#define __STDCXX_VERSION__ 200610L
I think it's a good idea to have a pre-defined macro indicating that
we're in C++0x mode. Eventually, I suppose, that macro will be
"__cplusplus", which will have the date of the future C++0x standard.
I'm not sure if it would be a good idea to bump __cplusplus in C++0x
mode now, or not, but it seems worth considering.
(In theory, a binary macro (C++0x experimental mode vs. standard C++99
mode), is enough: that, together with the compiler version number, tells
you what features you have to work with. I'm not saying this is the
best suggestion, though; it's just a possibility.)
So, with that amendment, i.e., with the addition of:
(d) predefine a macro (or macros) that indicates that we're in C++0x mode
are there objections to the policy set out above? Point (d) doesn't
mean that we can't predefine many macros (for various features) or that
we have to use any particular value; it's just saying that we'll give
users some way of figuring out what dialect of C++ they're using.
If there are no objections, I would like to submit it to the SC. I will
wait at least 72 hours for objections/comments, as I would like to
present this to the SC as a consensus of the key C++ stakeholders; if
it's not actually such a consensus, then I would prefer to iterate until
we do reach such a consensus.
I'm not meaning to the close the door on variadic templates or rvalue
references with this policy; we can always make an exception if we're
convinced that a particular feature is worth including. So, agreeing to
the policy above does not mean that you agree that variadic templates
should not be included in the compiler; it just means that you think the
policy is a reasonable choice, in general.
(650) 331-3385 x713