This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++ PATCH: PR 20599 (1/3)
[re-sending to the list]
On Sep 24, 2006, at 2:22 PM, Mark Mitchell 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.
What do people think of that suggestion?
This is a reasonable policy.
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.
Since the policy we're agreeing on excludes variadic templates from
consideration, I'd like to see this patch discussed on its own
merits. Variadic templates are a huge win for libstdc++. They take
the ugliest parts of libstdc++, the TR1 function objects and tuple
implementations, and improve them greatly, both for libstdc++
maintainers and for users. We can eliminate more than 50k of
repetitive code from libstdc++, replacing a barely-maintainable mess
of preprocessor metaprogramming with a simple, concise implementation
that compiles in less than 1/10th of the time. Moreover, the variadic-
template--enabled libstdc++ provides a better user experience. The
current implementation limits the number of parameters to function/
bind/mem_fn/etc. to 10; try to use 11 parameters and you get a big,
ugly error message. We can't even bump up the maximum number of
parameters supported by the library (we've tried), because compile
times become prohibitive.
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++.
Cheers,
Doug