c++0x implementation and compatibilty thoughts

[bkoz <benjamin dot kosnik at gmail dot com>]

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:

1) C++0x means working draft. Period. If the draft changes,
  implementation changes.  When C++0x is not a draft, C++0x code will
  transform into C++09 code, date to be determined.

2) Reuse vs. Readability. This means reusing as much of C++98 + TR1
  code as possible, while at the same time keeping sources
  readable. If it becomes necessary to do parallel libstdc++-v3 and
  libstdc++-v3 code, try to re-use as much as possible. Keep
  duplication to a minimum. At some stage, this may not be possible:
  obfuscation should be monitored and kept within acceptable limits.

3) Be able to test divergence between well-specified versions. In particular:
 a) C++03 vs. C++0x differences.
 b) TR1 vs. C++0x

 There is an effort on the LWG wiki to document changes and
 deprecated proposals. With luck, Matt Austern and I will magically
 turn this into a paper for post-Oxford.

4) Try to do all this by using the language as defined by the C++0x
  standard, with as few extensions as possible.


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
}

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.

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.

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

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

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

Some previous commentary on these issues:

"[v3] c++0x includes"
http://gcc.gnu.org/ml/libstdc++/2007-02/msg00152.html

"PR 31426: TR1 and the Experimental C++0x Mode"
http://gcc.gnu.org/ml/libstdc++/2007-04/msg00039.html


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.

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.


Anyway. I know this is a lot but I figured it best to get it out in public.

-benjamin
#if 1
#include <tuple>
#include <tr1/tuple>
#else
#include <tr1/tuple>
#include <tuple>
#endif

// mixed mode basics: work?

int main()
{
  std::tr1::tuple<int, double> x(17, 3.14);
  std::tuple<int, double> y(17, 3.14);

  return 0;
}

#include <tuple>

// -std=c++0x only shouldn't have tr1 items

namespace tr1
{
  template<typename T1, typename T2>
  class tuple { };
}

int main()
{
  using namespace std;
  tuple<int, double> y(17, 3.14);

  tr1::tuple<int, double> x; // should work

  return 0;
}

#if 1
#include <array>
#include <tr1/array>
#else
#include <tr1/array>
#include <array>
#endif

struct A { };

// Should be able to specialize both?
namespace std
{
  namespace tr1
  {
    template<>
      struct array<A, 5> { };
  }
}

namespace std
{
  template<>
      struct array<A, 5> { };
}

#include <tr1/tuple>
#include <tuple>
#include <array>

// including both tr1 tuple and std::tuple shouldn't magically make
// tr1::array appear.

int main()
{
  std::tr1::array<int, 5> a; // error
  return 0;
}