12

I just restarted working on a project which has been on hold for a few months. Last time I compiled it it was working just fine, without any error nor warning. Yet when I tried to compile it earlier today I got this warning

attention : ‘template<class _Operation> class std::binder2nd’ is deprecated [-Wdeprecated-declarations]

This warning literally appears hundreds of time when including Eigen/Geometry, which I use all over my project

In file included from [...]/include/Eigen/src/Core/ArrayBase.h:109:0,
                 from [...]/include/Eigen/Core:350,
                 from [...]/include/Eigen/Geometry:4,
                 from [...]/include/[myproject]/types.hh:8,
                 from [...]/include/[myproject]/voronoi.hh:8

Since then I haven't updated Eigen (is used 3.2.4 which is still the last update today). However, since last time I compiled it, GCC has been updated to 5.1.0 (I'm using archlinux)

Question:

  • Is there an issue with gcc 5.1.0 telling me std::binder2nd is deprecated
  • Should Eigen be updated ?
  • How can I silent those specific warning without loosing the verbosity of my build ?

ANSWER

I appreas that std::bind2nd is really deprecated and that a commit has been done to solve that in Eigen. This commit is however not yet merged with the master branch :/ (and doesn't solve the issue as some std::bind2nd are still present in Eigen's code)

Bottom line is: Eigen's last stable version is deprecated

Amxx
  • 3,020
  • 2
  • 24
  • 45
  • In case you were wondering: since C++11 you are encouraged to use `std::bind` instead of `std::bind2nd` (or its sister `std::bind1st`). `std::bind` is a variadic template. – András Aszódi May 29 '15 at 18:16
  • @user465139: I know always used `std::bind` and didn't even knew about `std::bind2nd`. However, the issue here is happening in Eigen which I obviously havent written myself – Amxx May 29 '15 at 18:18
  • thx for your comment, now I realise that my comment was easy to misunderstand. I did not mean that it's your "fault", obviously it is up to the Eigen developers to change this. What I wanted to say that `std::bind` is the recommended function to be used. My comment was intended to help those who maybe did not know about `std::bind` but I expressed myself a bit clumsily... – András Aszódi May 30 '15 at 16:34
  • @Amxx Would you mind removing the answer from the question and posting it as the accepted answer? – Avi Ginsburg Jun 04 '15 at 08:17
  • 1
    The warning message itself tells you that this warning is controlled by `-Wdeprecated-declarations` flag. Thus to (temporarily) get rid of these warnings, compile with the `-Wno-deprecated-declarations` flag. – Ilya Popov Jun 09 '15 at 22:17
  • 1
    Another thing you can do, is to specify Eigen's include dir with `-isystem` instead of `-I` flag to gcc (for cmake it is `include_directories(SYSTEM ...)`). This way warnings originated from Eigen includes will not be shown. – Ilya Popov Jun 09 '15 at 22:24

3 Answers3

11
  • Is there an issue with gcc 5.1.0 telling me std::binder2nd is deprecated

No, the C++ standard says it's deprecated in C++11, so if you compile in C++11 mode then it is supposed to be deprecated.

  • Should Eigen be updated ?

Yes. if it wants to be C++17 compatible, as std::bind2nd doesn't exist post-C++14 at all.

  • How can I silent those specific warning without loosing the verbosity of my build ?

Suppress the warning. Either compile with -Wno-deprecated-declarations on the command-line or do it in the source when including the Eigen headers:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
#include <eigen/whatever.h>
#pragma GCC diagnostic pop

Or, as the other answer says, tell GCC to treat the Eigen headers as system headers, which happens automatically if they are in /usr/include, or are included with -isystem, or are included from another header that does:

#pragma GCC system_header
#include <eigen/whatever.h>
Jonathan Wakely
  • 166,810
  • 27
  • 341
  • 521
  • "which happens automatically if they are in `/usr/include`" - I was not aware of this. Apparently it doesn't apply to subdirectories? – Jake Sep 29 '15 at 22:41
  • 1
    @Jake gcc implicitly does -isystem /usr/include. If you add -I /usr/include/eigen3, you are not covered by this. – Marc Glisse Sep 30 '15 at 04:10
  • @MarcGlisse Could you elaborate on "not covered by this"? Applying the `-isystem` argument to `/usr/include/eigen3` removed the warnings for me, where before I was getting them even though `eigen3` is a subdirectory of `/usr/include`, an implicit `isystem` directory. Are you saying that this is expected, or not? – Jake Oct 01 '15 at 06:19
  • That's expected, and doesn't contradict what Marc said. He said that `/usr/include` is a system directory by default, but using `-I /usr/include/eigen3` (note `-I` not `-isystem` !) makes it a _non_-system directory, so you don't get the usual treatment for everything under `/usr/include`. Using `-isystem` doesn't have that effect, because `-isystem` is not `-I` – Jonathan Wakely Oct 01 '15 at 09:53
1

How can I silent those specific warning without loosing the verbosity ?

Edit the CMakeLists.txt file. Add this line somewhere after CMAKE_CXX_FLAGS is set.

SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-deprecated-declarations")

Previous answer mentioned adding this to #pragma or to command line. I am biased against #pragma because I find it hard later on to remember where I put it. So as general practice, I try to avoid #pragma. Adding to command line means you have to remember to type this everytime you recompile.

Vignesh
  • 111
  • 4
0

Instead of using the -I flag to include files use -isystem to include Eigen headers:

g++-5 -isystem/usr/include/eigen3 source_file_here.cpp

This flag is intended for system headers that don't conform to C standards but are considered false positives when warnings are generated. Eigen headers are used much like system headers and thus for most users the warnings are not helpful but merely an annoying false positive.

Credit goes to Ilya Popov's comment in the original question.

Community
  • 1
  • 1
Jake
  • 7,565
  • 6
  • 55
  • 68
  • _"This flag is intended for older system headers [...]"_ That's not an accurate description of the purpose of the flag. It just tells the compiler to treat the directory as a system include directory. As a side-effect that suppresses warnings by default, but there is no presumption of those headers being old, or non-conforming. GCC's own C++ library headers are treated as system headers, but are not old headers that don't conform to modern C++ standards. – Jonathan Wakely Sep 29 '15 at 12:18
  • @JonathanWakely Thanks for pointing that out, description has been updated. – Jake Sep 29 '15 at 22:15
  • _"This flag is intended for system headers that don't conform to C standards"_ Still nope. It's just for treating things as system headers, with no presumption of non-conformance. – Jonathan Wakely Sep 30 '15 at 09:48
  • @JonathanWakely From gcc.gnu.org, linked in my answer: "The header files declaring interfaces to the operating system and runtime libraries often cannot be written in **strictly conforming C**. Therefore, GCC gives code found in system headers special treatment." – Jake Oct 04 '15 at 22:34