In commit c280e90, support for rvalue references was added. That same commit introduced a define "EIGEN_HAVE_RVALUE_REFERENCES". For gcc, this is set to true any time __GXX_EXPERIMENTAL_CXX0X__ is defined. This makes sense; rvalue references were introduced at the same time as that macro (in gcc 4.3). That said, there is code that is enabled by this macro that uses "nullptr"--a feature that wasn't introduced until gcc 4.6.
The upshot is that gcc 4.3, 4.4, and 4.5 can not #include <Eigen/Dense> when the -std=c++0x flag is in use.
My suggestion: replace the use of nullptr with 0 to retain compatibility with old compilers.
I don't really see the point in supporting experimental features of pretty old compiler versions, if you need C++11 features, then use a compiler that truly support it. (gcc 4.6 was released almost 5 years ago).
Today, replacing nullptr by 0 might be enough, but tomorrow Eigen will very likely rely on other non implemented C++11 features in such old compiler in C++11 mode.
(In reply to Gael Guennebaud from comment #1)
> I don't really see the point in supporting experimental features of pretty
> old compiler versions, if you need C++11 features, then use a compiler that
> truly support it. (gcc 4.6 was released almost 5 years ago).
> Today, replacing nullptr by 0 might be enough, but tomorrow Eigen will very
> likely rely on other non implemented C++11 features in such old compiler in
> C++11 mode.
It would be great if it were up to me, but the compiler versions I am required to support at work is not my decision.
It's not really that I want Eigen to support some C++11 features, it's that I do not want it to assume that C++11 is fully implemented when it detects experimental support via the aforementioned macro and then fail to compile.
One other way to do this would be to add a way to forcefully disable C++11 (e.g., EIGEN_NO_CXX11).
I guess we should simply remove the line
defined(__GXX_EXPERIMENTAL_CXX0X__) || \
from Macros.h (and perhaps any other reference to __GXX_EXPERIMENTAL_CXX0X__, if there are any?). We do claim to support GCC 4.1 and newer -- but we don't promise to support experimental extensions.
oh, right, those should definitely be removed!
Fixed in devel and 3.2:
There are two references left in unsupported/test/mpreal/mpreal.h which I did not touch, as they should not influence Eigen itself in any way.
-- GitLab Migration Automatic Message --
This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/1153.