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

[Gabriel Dos Reis]

"Benjamin Kosnik" <bkoz@redhat.com> writes:

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

Do we really need to warn about auto_ptr<>?

-- Gaby