c++0x implementation and compatibilty thoughts

[Benjamin Kosnik]

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