public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/59325] New: Provide a way to disable deprecated warnings
@ 2013-11-28  8:40 andysem at mail dot ru
  2013-11-28 11:14 ` [Bug libstdc++/59325] " redi at gcc dot gnu.org
                   ` (8 more replies)
  0 siblings, 9 replies; 10+ messages in thread
From: andysem at mail dot ru @ 2013-11-28  8:40 UTC (permalink / raw)
  To: gcc-bugs

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug libstdc++/59325] Provide a way to disable deprecated warnings
  2013-11-28  8:40 [Bug libstdc++/59325] New: Provide a way to disable deprecated warnings andysem at mail dot ru
@ 2013-11-28 11:14 ` redi at gcc dot gnu.org
  2013-11-28 11:43 ` andysem at mail dot ru
                   ` (7 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2013-11-28 11:14 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
You can use a #pragma to disable -Wdeprecated locally


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug libstdc++/59325] Provide a way to disable deprecated warnings
  2013-11-28  8:40 [Bug libstdc++/59325] New: Provide a way to disable deprecated warnings andysem at mail dot ru
  2013-11-28 11:14 ` [Bug libstdc++/59325] " redi at gcc dot gnu.org
@ 2013-11-28 11:43 ` andysem at mail dot ru
  2013-11-28 12:23 ` redi at gcc dot gnu.org
                   ` (6 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: andysem at mail dot ru @ 2013-11-28 11:43 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #1)
> You can use a #pragma to disable -Wdeprecated locally

But the legacy C++ is used in the library, which code I'd like to avoid
changing.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug libstdc++/59325] Provide a way to disable deprecated warnings
  2013-11-28  8:40 [Bug libstdc++/59325] New: Provide a way to disable deprecated warnings andysem at mail dot ru
  2013-11-28 11:14 ` [Bug libstdc++/59325] " redi at gcc dot gnu.org
  2013-11-28 11:43 ` andysem at mail dot ru
@ 2013-11-28 12:23 ` redi at gcc dot gnu.org
  2013-11-28 13:03 ` andysem at mail dot ru
                   ` (5 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2013-11-28 12:23 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Doing this before any other includes will work:

#include <bits/c++config>
#undef _GLIBCXX_DEPRECATED
#define _GLIBCXX_DEPRECATED

I'm not convinced we want to support this officially.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug libstdc++/59325] Provide a way to disable deprecated warnings
  2013-11-28  8:40 [Bug libstdc++/59325] New: Provide a way to disable deprecated warnings andysem at mail dot ru
                   ` (2 preceding siblings ...)
  2013-11-28 12:23 ` redi at gcc dot gnu.org
@ 2013-11-28 13:03 ` andysem at mail dot ru
  2014-12-21 11:10 ` redi at gcc dot gnu.org
                   ` (4 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: andysem at mail dot ru @ 2013-11-28 13:03 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #3)
> Doing this before any other includes will work:
> 
> #include <bits/c++config>
> #undef _GLIBCXX_DEPRECATED
> #define _GLIBCXX_DEPRECATED
> 
> I'm not convinced we want to support this officially.

Yes, I'm doing something like that now, although I also have to detect that
we're using libstdc++. And I also have no easy way to add that code in every
.cpp file I have in my project, so I have to resort to -include command line
argument for gcc. That, in turn brings additional complications of detecting
which files need that tweak (i.e. C++ files) and which don't (i.e. C files). I
just think that all these hoops could be avoided if libstdc++ was a little more
friendly in this regard. After all, there's no harm in using e.g. auto_ptr in
C++11 code, it surely won't disappear from STL any time soon, so the warning is
a bit overreactive anyway.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug libstdc++/59325] Provide a way to disable deprecated warnings
  2013-11-28  8:40 [Bug libstdc++/59325] New: Provide a way to disable deprecated warnings andysem at mail dot ru
                   ` (3 preceding siblings ...)
  2013-11-28 13:03 ` andysem at mail dot ru
@ 2014-12-21 11:10 ` redi at gcc dot gnu.org
  2020-10-20 14:28 ` redi at gcc dot gnu.org
                   ` (3 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2014-12-21 11:10 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -78,11 +78,13 @@
 # define _GLIBCXX_USE_DEPRECATED 1
 #endif

+#ifndef _GLIBCXX_DEPRECATED
 #if defined(__DEPRECATED) && (__cplusplus >= 201103L)
 # define _GLIBCXX_DEPRECATED __attribute__ ((__deprecated__))
 #else
 # define _GLIBCXX_DEPRECATED
 #endif
+#endif

 // Macros for ABI tag attributes.
 #ifndef _GLIBCXX_ABI_TAG_CXX11


This would allow you to just define _GLIBCXX_DEPRECATED="" unconditionally


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug libstdc++/59325] Provide a way to disable deprecated warnings
  2013-11-28  8:40 [Bug libstdc++/59325] New: Provide a way to disable deprecated warnings andysem at mail dot ru
                   ` (4 preceding siblings ...)
  2014-12-21 11:10 ` redi at gcc dot gnu.org
@ 2020-10-20 14:28 ` redi at gcc dot gnu.org
  2020-10-20 14:32 ` redi at gcc dot gnu.org
                   ` (2 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2020-10-20 14:28 UTC (permalink / raw)
  To: gcc-bugs

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-10-20
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to andysem from comment #2)
> (In reply to Jonathan Wakely from comment #1)
> > You can use a #pragma to disable -Wdeprecated locally
> 
> But the legacy C++ is used in the library, which code I'd like to avoid
> changing.

Is this still a problem? Uses of deprecated features within the library itself
should no longer emit warnings (I think I've disabled them with pragmas).

So the only uses should be in our own code, which you can add pragmas to.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug libstdc++/59325] Provide a way to disable deprecated warnings
  2013-11-28  8:40 [Bug libstdc++/59325] New: Provide a way to disable deprecated warnings andysem at mail dot ru
                   ` (5 preceding siblings ...)
  2020-10-20 14:28 ` redi at gcc dot gnu.org
@ 2020-10-20 14:32 ` redi at gcc dot gnu.org
  2020-10-20 14:46 ` andysem at mail dot ru
  2020-10-20 16:07 ` redi at gcc dot gnu.org
  8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2020-10-20 14:32 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to andysem from comment #4)
> I just think that all these hoops could be avoided if libstdc++ was a little
> more friendly in this regard. After all, there's no harm in using e.g.
> auto_ptr in C++11 code, it surely won't disappear from STL any time soon, so
> the warning is a bit overreactive anyway.

Well it is gone from the recent standards, and is not longer defined by other
std::lib implementations when compiling with newer standards, e.g. libc++
doesn't define it in C++17 mode. That's exactly what the warning is telling
you: you're using a feature which is going away.

If you want to ignore the warning because you know you're not going to use a
different implementation or a newer standard, you can use -Wno-deprecated to
disable all such warnings globally or use #pragma to disable them locally.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug libstdc++/59325] Provide a way to disable deprecated warnings
  2013-11-28  8:40 [Bug libstdc++/59325] New: Provide a way to disable deprecated warnings andysem at mail dot ru
                   ` (6 preceding siblings ...)
  2020-10-20 14:32 ` redi at gcc dot gnu.org
@ 2020-10-20 14:46 ` andysem at mail dot ru
  2020-10-20 16:07 ` redi at gcc dot gnu.org
  8 siblings, 0 replies; 10+ messages in thread
From: andysem at mail dot ru @ 2020-10-20 14:46 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #8 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to andysem from comment #2)
> > (In reply to Jonathan Wakely from comment #1)
> > > You can use a #pragma to disable -Wdeprecated locally
> > 
> > But the legacy C++ is used in the library, which code I'd like to avoid
> > changing.
> 
> Is this still a problem? Uses of deprecated features within the library
> itself should no longer emit warnings (I think I've disabled them with
> pragmas).
> 
> So the only uses should be in our own code, which you can add pragmas to.

Yes, this is still a problem. To be clear, the library I was referring to was
not libstdc++ but another library which I have no control of and which is still
using C++03 features. I don't think it will move away from std::auto_ptr any
time soon as it is part of the API.

> If you want to ignore the warning because you know you're not going to use a
> different implementation or a newer standard, you can use -Wno-deprecated to
> disable all such warnings globally or use #pragma to disable them locally.

I don't want to disable _all_ deprecated warnings universally, only those
emitted by libstdc++. For this reason I cannot use -Wno-deprecated. #pragma
also doesn't really work because libstdc++ can be included from any header,
including those from other libraries, for which I don't want to disable
warnings.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug libstdc++/59325] Provide a way to disable deprecated warnings
  2013-11-28  8:40 [Bug libstdc++/59325] New: Provide a way to disable deprecated warnings andysem at mail dot ru
                   ` (7 preceding siblings ...)
  2020-10-20 14:46 ` andysem at mail dot ru
@ 2020-10-20 16:07 ` redi at gcc dot gnu.org
  8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2020-10-20 16:07 UTC (permalink / raw)
  To: gcc-bugs

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
           Keywords|                            |diagnostic

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Confirming as an enhancement request.

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2020-10-20 16:07 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-28  8:40 [Bug libstdc++/59325] New: Provide a way to disable deprecated warnings andysem at mail dot ru
2013-11-28 11:14 ` [Bug libstdc++/59325] " redi at gcc dot gnu.org
2013-11-28 11:43 ` andysem at mail dot ru
2013-11-28 12:23 ` redi at gcc dot gnu.org
2013-11-28 13:03 ` andysem at mail dot ru
2014-12-21 11:10 ` redi at gcc dot gnu.org
2020-10-20 14:28 ` redi at gcc dot gnu.org
2020-10-20 14:32 ` redi at gcc dot gnu.org
2020-10-20 14:46 ` andysem at mail dot ru
2020-10-20 16:07 ` redi at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).