This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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] |
On Sep 25, 2006, at 9:58 AM, Howard Hinnant wrote: > I would prefer something more like: > > g++ my_source.cpp -enable_rvalue_refs -enable_variadic_templates - > enable_static_assert -lboost -lAcme
Whereas I would prefer, e.g.,
g++ -std=c++0x -lboost -lAcme
Otherwise, users need to track exactly what we're done in each minor release to try out these features. For instance, with GCC 4.3.0 users might need to write:
g++ my_source.cpp -enable_rvalue_refs -enable_variadic_templates - enable_static_assert -lboost -lAcme
Then for GCC 4.3.1 we implement more of the C++0x working draft, so we now have:
g++ my_source.cpp -enable_rvalue_refs -enable_variadic_templates - enable_static_assert -enable-decltype -enable-auto -lboost -lAcme
Then maybe the committee changes its mind, so we yank a feature [*] from GCC 4.3.2 and get:
g++ my_source.cpp -enable_rvalue_refs -enable_variadic_templates - enable-decltype -enable-auto -lboost -lAcme
Now users need to determine the patch level of g++ to enable C++0x features. If we have one flag, the variance in features from version to version will be queried through feature-test macros (supplied by the compiler). Users just decide whether they want the C++0x features or not.
When C++0x goes out the door, we add -std=c++09 (just guessing <g>) for the new standard and deprecate -std=c++0x. It's not much different from what we're already doing with -std=c9x and -std=c99.
Well, this exactly points at the problem we are facing with adding extensions for future parts of the C++0x standard. We do _not_ want to encourage "persistent" use of the new features (which can and will vanish at any point without backwards compatibility).
This practically means the compiler should just provide _one_ -std=c++0x-draft (or whatever name) and _not_ provide preprocessor macros for features included in the particular release. This avoids giving false promises about stability of these language extensions.
Uses in gccs own standard library implementation are "fine" in the sense that at the point of implementation we know the feature set we can rely on. Of course something like #pragma gcc C++0x would be needed to enable the language features for a subset of a translation unit. Or we would need to provide fallback implementations conforming to the current C++ standard, which would be against the purpose of using the new features in our library implementation. Of course special care needs to be take to remain ABI and Interface compatible between implementations where required.
I still suggest somebody goes forward and creates a C++0x branch and implements the suggested changes.
Thanks, Richard.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |