[v3] annex D 8 and 9 for C++0x

[Benjamin Kosnik]

Hey y'all.

This implements Annex D, parts 8 and 9, from N2369. (Ie, the most
recent C++0x draft at this time.) Which implies the deprecation of
std::auto_ptr, std::binder1st, std::bind1st, std::binder2nd,
std::bind2nd, but only when compiling in C++0x mode.

So, no need for people to freak out: the normal C++98/03 code paths
and behaviors are unchanged.

Here's the low-down on behavior:

1) in c++98:
    <functional> has binder1st, bind1st, binder2nd, bind2nd
    <memory> has auto_ptr

     There is no warning for the use of these constructs.

2) in c++0x:
    <functional> has binder1st, bind1st, binder2nd, bind2nd
    <memory> has auto_ptr

    Use of these features warns about deprecation. (Or will warn.)
    As is our current usage, -Wno-deprecated kills the warning. In
addition,   -Wno-deprecated-declarations also kills the warning for
these items.

3) in c++0x with -D_GLIBCXX_USE_DEPRECATED=0
    <functional> does not have binder1st, bind1st, binder2nd, bind2nd
    <memory> does not have auto_ptr

I believe this to be a sane deprecation plan, but am interested in
hearing feedback. Note, this is a bit different from previous
g++/libstdc++ releases, where deprecated bits were not around, and
_GLIBCXX_DEPRECATED had to enable them. I don't believe that was/is
standards-conforming. Although, the one thing that was deprecated this
way (streambuff:stossc), has never had a complaint.

Still  needed:

1) Resolution to __attribute__ deprecated usage in c++
http://gcc.gnu.org/PR33912

2) Should -Wno-deprecated imply -Wno-deprecated-declarations in C++?
IMHO the GCC manual for -Wno-deprecated implies this to me, and the
attached patch implements this.

3) I'd like to move the relevant bits around in the testsuite
directory, so that auto_ptr and the deprecated binders are in
backwards. In addition, I'll have to mark up these files so that they
pass when tested in c++0x mode. This will mean adding dg-options for
-Wno-deprecated or -Wno-deprecated-declarations, when 1 is fixed. I
can do this later.

tested x86/linux

-benjamin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: p.20071026-2
Type: application/octet-stream
Size: 35235 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20071026/274956f3/attachment.obj>