This is the mail archive of the gcc-patches@gcc.gnu.org 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: C++ PATCH: PR 20599 (1/3)


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.


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

Thanks,

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


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