c++0x implementation and compatibilty thoughts

Douglas Gregor doug.gregor@gmail.com
Thu Apr 26 19:15:00 GMT 2007


On Thu, 2007-04-26 at 20:41 +0200, bkoz wrote:
> Here is a summary of my current thinking and outstanding issues WRT
> C++0x support, integrating this into our existing TR1, C++98, and
> C++03 support.
> 
> Goals and Definitions:

Agreed on all counts...

> 
> Includes:
> 
> The current approach.
> 
>  -std=c++98
> 
> gives:
> 
> namespace std
> {
>   namespace __debug;
>   namespace tr1;
> }
> 
>  -std=c++0x
> 
> namespace std
> {
>   namespace __cxx200x; // namespace aliased to std::
>   namespace __debug;
>   namespace tr1; // in dispute as to what this means
> }

Right.

> In addition, there are a couple of options for further partitioning.
> 
> Option 1: partition C99. Add nested C99 namespace, as follows:
> 
> namespace std
> {
>   namespace __c1999; // namespace aliased to std:: when using C99
>   ...
> }
> 
> This would move C99 bits out of __gnu_cxx and give the ability to
> inject in one place. Also, it would visibly define C99 support,
> probably making things clearer.

Should __c1999 be aliased to std:: in C++0x mode? C++0x has adopted most
(all?) of the C99 library changes...

> Option 2: partition C++98. Add nested C++98 namespace, as follows:
> 
> namespace std
> {
>   namespace __cxx1998; // namespace aliased to std:: (when not using C++0x?)
>   ...
> }
> 
> Astute observers will realize that this would flip the debug-mode
> organization on, permanently. Thus, the debug mode's "__norm" becomes
> "__cxx1998." I've wanted to do this for some time. Breaks ABI.

I don't have an opinion on this.

> For the include/namespace strategy, it's probably best to start out
> defining how things should work, and then coming up with specific
> examples and problem areas.
> 
> Things to be defined:
> 1) multiple inclusion <type_traits>, <tr1/type_traits>.
> 
> If you include both, do both work?

They should.

>  If not, is the diagnostic an error
> or a warning? If you include both, do you get C++0x and TR1 behavior?
> Or C++0x and TR1+modifications behavior?

C++0x behavior from components in namespace std, TR1 behavior from
components in namespace std::tr1. 

> 2) usage of C++0x includes in C++98: warn or error. (Current
>    include/std/c++0x_warning.h behavior errors.)

Error. In an ideal world, they wouldn't even show up, e.g., including
<tuple> in a C++98 program would just come back with the equivalent of
"file not found." But, an #error will do.

> I've attached 4 or 5 problem areas to think about to this email.
> You'll find them as "mixed_mode_*.cc".

I think all of these examples should compile without errors.

> Binaries:
> 
> 1) Iff C++0x != C++98, would like to mine libstdcxx_so_7-branch for as
>    much as possible and use it. This is why we had this branch... In
>    particular, versa string as the default, and the template cleanups
>    that Chris Jefferson did.
> 
> 2) Iff C++0x != C++98, I will push to use the namespace association
>    versioning code path for the versioning strategy instead of the
>    current gnu.ver. (This is a sub-note from 1). I'm going to be
>    upfront about this. By doing this, there exists a way to
>    disambiguate weak symbols between C++0x and C++98. Meaning a
>    possibility for mixed mode working, dll/plugins working, etc. Prior
>    art exists from FC5 libstdc++so07 package. I think it would make
>    sense to continue so.6 as the C++98 compatible thing, and C++0x
>    would be so.7.

Interesting. Well, I think it's guaranteed that C++0x will break the
library's ABI, so we might as well take that opportunity to make all of
the other ABI-breaking changes that we need to make to move libstdc++
forward.

> 3) Iff C++0x != C++98, g++ -fabi should be bumped as well. ie,
>    -fabi-version=3 should be the default for C++0x. If possible, it would
>    be great to keep g++ able to do both ABI's and C++98/C++0x. If not,
>    same rules as for library... clean break.

I'm fairly certain that the C++0x ABI will be a superset of the C++98
ABI. New C++0x features will require extensions to the ABI, but they
should be pure extensions, e.g., new name mangling rules for concepts,
rvalue references, and variadic templates, but no changes to existing
name mangling rules. Among other things, this means that a C++0x
compiler should be able to use a C++98 library and interoperate with a C
++98 compiler using that same C++98 library.

  - Doug



More information about the Libstdc++ mailing list