[v3] c++0x includes

[Gabriel Dos Reis]

Benjamin Kosnik <bkoz@redhat.com> writes:

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

That is one of the worst inventions the LWG ever made.  Stunning.

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

However, there is no guarantee they weill go away (from the standard).
As curious as it may be -- and this is a fact -- "deprecated" has no
meaningful implication from the semantics point of view.  I highly
suspect almost none of the deprecated stuff will go away.

May <complex.h> rest in peace.

-- Gaby