[Bug libstdc++/59325] Provide a way to disable deprecated warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59325 Jonathan Wakely changed: What|Removed |Added Status|WAITING |NEW Keywords||diagnostic --- Comment #9 from Jonathan Wakely --- Confirming as an enhancement request.
[Bug libstdc++/59325] Provide a way to disable deprecated warnings
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.
[Bug libstdc++/59325] Provide a way to disable deprecated warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59325 --- Comment #7 from Jonathan Wakely --- (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.
[Bug libstdc++/59325] Provide a way to disable deprecated warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59325 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2020-10-20 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #6 from Jonathan Wakely --- (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.
[Bug libstdc++/59325] Provide a way to disable deprecated warnings
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
[Bug libstdc++/59325] Provide a way to disable deprecated warnings
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
[Bug libstdc++/59325] Provide a way to disable deprecated warnings
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.
[Bug libstdc++/59325] Provide a way to disable deprecated warnings
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.
[Bug libstdc++/59325] Provide a way to disable deprecated warnings
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.
