This is the mail archive of the
mailing list for the GCC project.
Re: C++ PATCH: PR 20599 (1/3)
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Benjamin Kosnik <bkoz at redhat dot com>, 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: 02 Oct 2006 03:40:11 +0200
- 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> <45202D43.email@example.com>
Mark Mitchell <firstname.lastname@example.org> writes:
| 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
| >>> features,
| >>> (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.
| > Say:
| > #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.
I suspect we want to see __cplusplus to retain the value stated in the
last official version of C++ (though we have a long standing PR there).
| (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?
I would like to see a flag -std=c++03, in addition to -std=c++0x.
Other than, that I suspect your proposed plan is a good one, as long
as we all understand its implications.