Eigen & GCC 5 : class std::binder2nd is deprecated

Question

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

Dara

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. – Kirkcudbright

@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 – Dara

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... – Kirkcudbright

@Dara Would you mind removing the answer from the question and posting it as the accepted answer? – Chaudfroid

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. – Selig

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. – Selig

Answer 1

• 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>

Allheal

"which happens automatically if they are in /usr/include" - I was not aware of this. Apparently it doesn't apply to subdirectories? – Moritz

@Moritz gcc implicitly does -isystem /usr/include. If you add -I /usr/include/eigen3, you are not covered by this. – Twitty

@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? – Moritz

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 – Allheal

Answer 2

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.

Lapland

Answer 3

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.

Moritz

"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. – Allheal

@JonathanWakely Thanks for pointing that out, description has been updated. – Moritz

"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. – Allheal

@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." – Moritz