Re: c++0x implementation and compatibilty thoughts

[Benjamin Kosnik <bkoz at redhat dot com>]

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

Right now we partition this as C99 math, wchar_t, and all at 
configure/build time. Some targets for g++ don't have complete C99 
support, but still want wstring, etc.

Then, on some targets, (BSD?, others) you allow compile-time overrides. 
All this adds source complexity and maybe (just maybe, maybe not) this 
could be expressed more concisely.

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

I'm still a little leary of mixing items with the same name and 
different behavior in a namespace (std) and a nested namespace (std::tr1).

We should definitely try it though.


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

Yeah.

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

OK.

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

Agreed.

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

Cool.

I don't know what the -fabi-3 changes are: I leave this to the C++ FE 
maintainers. I was just stating "if we're bumping, then it makes sense 
to both bump."

It will be interesting to see if there are differences between g++-abi-3 
+ c++0x and g++-abi-2 c++98.

best,
-benjamin