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

[Benjamin Kosnik <bkoz at redhat dot com>]

> > * 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.
> >
> > What do people think of that suggestion?
> 
> This is a reasonable policy.

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

That way, we can bump it in the future, and clearly disambiguate code.

Also, it will allow coherent compile time deprecation messages a la
include/backward/backward_warning.h:

#if  (__STDCXX_VERSION__ < REAL_DATE_OF_STANDARD)
#warning dont_even_think_of_compiling_this
#endif

> One part I'm not clear about is whether you envision this to be a  
> single flag (e.g., -std=c++0x, -std=gnu++0x) or whether it should be  
> multiple flags (-experimental-rvalue-ref, -experimental-decltype,  
> etc.). Personally, I have a strong preference for the single-flag  
> approach, for two reasons:
>    (1) It doesn't force the user to think about which features s/he  
> is enabling to "try out a C++0x compiler." One flag enables all that  
> GCC supports; the documentation and feature-test macros tell us what  
> those features are.
>    (2) All of these features have to work together anyway. If they  
> don't work together in the language, we need to know early; if they  
> don't work together in the compiler, they don't belong in an FSF  
> release.

For the record, I fall into the one-flag to rule them all approach as well.

> GCC already contains other extensions meant to improve libstdc++,  
> such as extern templates and strong using directives. The former  
> helps improve compile times (among other benefits) and has now become  
> part of the C++0x working draft. The latter helps improve the user  
> experience for libstdc++'s debug mode. Varadic templates do both, and  
> drastically simplify one of the worst parts of libstdc++.

FYI debug mode functionality is motivating a lot of the plugins/shared
library discussion. It's assumed that whatever sticks will also provide
a standardized way to do what's being done with namespace association
and debug mode.

-benjamin