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