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]

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


On 9/25/06, Doug Gregor <dgregor@cs.indiana.edu> wrote:

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]