This is the mail archive of the 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)

[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++.


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