This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3] annex D 8 and 9 for C++0x
- From: Gabriel Dos Reis <gdr at cs dot tamu dot edu>
- To: "Benjamin Kosnik" <bkoz at redhat dot com>
- Cc: libstdc++ <libstdc++ at gcc dot gnu dot org>, gcc-patches at gcc dot gnu dot org
- Date: 26 Oct 2007 13:36:11 -0500
- Subject: Re: [v3] annex D 8 and 9 for C++0x
- References: <9f71cef00710260925s2a1c8662n570849103f709695@mail.gmail.com>
"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