[v3] c++0x includes

[Benjamin Kosnik <bkoz at redhat dot com>]

This adds C++0x includes when -std=c++0x.

I'm posting this mostly for feedback, as there are a couple of issues 
that deserve more discussion.

Notable issues:

1) Backward headers

Some of them absolutely have to go: complex.h, for instance, has to
go, as it is now specified as a TR1 include.

There has been some commentary about removing the backwards headers,
or a subset of the headers, or just the <complex.h> header in
bugzilla.

Here's a relevant bugzilla entry for complex.h:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13071

There was also some conversation about solving this issue. (I cannot
find the pinters to it, sorry.)

At the time, Gaby and Paolo stood on opposite sides of the issue. Gaby
suggested removing complex.h, and Paolo suggested removing all the
include files in include/backward. Stalemate.

From my vantage point today, I side with Paolo's position. I think
that C++0x means, by ISO rules, that items marked as deprecated
includes in C++98 should be removed from the libstdc++
sources. Formally, deprecated is defined as "Normative for the current
edition of the Standard, but not guaranteed to be part of the Standard
in future revisions."  Thus, all files in "includes/backward" get the
chop. All files in testsuite/backward get the chop. All docs that
reference these bits get the chop. Hiiiiii-ya!!!!

People (poor souls?) who'd like to use these facilities can always
download older releases.

People who are still using these headers have been warned for the last
five years that they are going away. This can hardly be a surprise.

There is one small nit, in that libstdc++.so.6 exports some strstream
symbols. As such, they should be preserved if we are to keep ABI
compatibility with the C++0x compiler. This condition can be
accomodated by hacking abi.cc to deal with this, and strstream.h can
still be removed from the installed includes.

2) "C" compatibility headers

The specifications for TR1 include specifications for what <tgmath.h>
and <complex.h> are. In particular, they seem to specify content that
is much different than the "C" or "C99" includes.

Two solutions exist, none particularly enticing.

a) resurrect the "C" compatibility includes. Ie, c vs. c_std includes.
This is what I did, but just for the problematic includes.

b) fixup the "C" includes, which was attempted, but then
discared. Numerous times.

3) C++98/C++0x interface issues

a) should C++0x includes warn when included without -std=c++0x, or just 
do nothing?

b) what happens when both TR1 and C++0x includes in the same translation 
unit? Ie, for debug mode, we have:


#include <debug/vector>
#include <vector>

int main()
{
  std::vector<int> v;
  __gnu_debug::vector<int> v2;
  return 0;
}

This works in normal and debug mode.

But:

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

int main()
{
  std::array<int, 5> v;
  std::tr1::array<int, 5> v2;
  return 0;
}

... are mutually exclusive in this patch.

without -std=c++0x, std::array falls down.
with -std=c++0x, std::tr1 falls down.

Although this seems like sensible behavior, I thought I'd point it out.


tested x86/linux

-benjamin

ps. FREE THE VARIADIC TEMPLATES

Attachment: p.20070221-1.bz2
Description: application/bzip