C++ PATCH: PR 20599 (1/3)

Mark Mitchell mark@codesourcery.com
Sun Oct 1 21:04:00 GMT 2006


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



More information about the Libstdc++ mailing list