[Bug libstdc++/59325] New: Provide a way to disable deprecated warnings

["andysem at mail dot ru" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59325

            Bug ID: 59325
           Summary: Provide a way to disable deprecated warnings
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: andysem at mail dot ru

In C++11 mode, libstdc++ marks some standard components from C++03 as
deprecated and emits warnings whenever these components are used. In particular
std::auto_ptr, std::bind1st and std::bind2nd are marked that way.

While the standard lists these components as deprecated, they are still used in
many libraries for portability reasons, so that the code compiles both in C++03
and C++11 modes. The problem is that the warnings are flagged not only for the
libraries but also for the client's code that uses them, and for the client
these warnings are useless and even harmful because they clutter the compiler
output. The suggested solution to disable the warnings by adding compiler
switches is too strong because not only libstdc++ warnings are disabled this
way but also other deprecated warnings too.

So, to sum up, my use case is as follows. Application A uses library B. A and B
are in C++11, but B uses C++03 legacy components for portability. B has its own
API and some parts of it get deprecated as new versions come out. The developer
of A is interested in seeing warnings about those API deprecation, but not
about B using legacy C++ internally.

My proposal is to add a configuration macro that, when defined by the user,
will disable deprecation warnings from libstdc++. This would solve the problem
in my example - the developer of A would define this macro and only see the
warnings from B and not libstdc++.