Hallo! This is continuation of the discussion from last year about compatibility, but I wanted to bring it up again, because I have some new data from my experience.
Our company uses Eigen extensively and has a larger ecosystem built on it, as do many of the voices on this list. We are in the embedded world, so we are often hindered to adapt quickly to new tools, very much like the HPC community has been. But we managed to move to C++14 with our codebase in 2019. When doing that, we somewhat monitored performance and compile time during the adaption. When we starting compiling our C++98 codebase as is with C+14, performance already went up slightly. C++14 does silently move or elide copies, and modern compiler have better optimizers, and the quality of implementation of STL types got better. So if you are at all bound by performance of STL types, I would really recommend using a new compiler in C++14 mode even with your old code. This was the obvious part. Another part was less obvious. We profiled compile time, which didn't change much after the switch and started to look into stuff which was expensive to compile. And then selectively in places, where the compile time was bad we simplified the code using C++14 features to improve compile time. This allowed us with very localized changes to cut our compile time by almost in half, while, at the same time, making the code in question often a lot simpler and new features (e.g. for performance improvements) easier to implement. This is also the experience which was observed with other template heavy codebases like boost::mpl in comparison to hana and other stuff. The gains in simplicity and compile time, especially from constexpr and lambda features are not minor. They can often cut your code in half and more than double the compile time. The problem is, I am at a point where its hard to do much more to improve the compile time of my codebase significantly, because most of the compile time is brought in by 2 libraries: boost.test and Eigen. We will most likely at some point abandon boost.test due to this, like many others have already (which slowed the development and improvement of boost.test further, while the alternatives got better and getting into this downwards spiral). I would be vary happy if I am not forced to abandon Eigen after the great 10 years we had with this library. In order to avoid this I pulled a lot of tricks like explicit template instatiations, tricks to reduce includes, even pimpl-like encapsulation at performance cost to isolate from the problem, but that gets you only so far. I may well be that my use case is special, but I strongly assume that new users which today want to adopt Eigen and have to look into its internals (as you inevitable need to do at some points), will see how its written and quickly run for alternatives. This amount of macros, boilerplate and similar stuff will be an argument against this great library some day and this day may already have come. The important part is here: Eigen compile time and internal expression template engine code readability it was great by 2010s standards, it was ok by 2015 standards, it is borderline by 2020 standards, and unless something changes, it will be unacceptable by 2025 standards, unless the Eigen library moves along. As C++ users, we do care about backwards compatibility greatly and that is even good for me, but we should not go the C way and care about too ancient compilers. The C++ comittee doesn't (that why int is required to be 2s complement in C++20), so Eigen library maintainers IMHO should follow. What are the chances to get Eigen 3.4 out of the door with C++98 support and drop it on the devel branch afterwards and jump to C++14? What is the Eigen promises about how old yours compilers may be? Can we explicitly agree on a statement like: We vow to support up to 3 year old compilers (or 5 years)? If we could agree on clear and conservative rules like we will go 3 years back or 5 years back and state these on the Eigen front page, Eigen user may look at our codebase and be much more willing to accept older standards code, knowing that it will improve over time and that the user gets some useful guarantees about the future in return. There is agrument to be made that if you use a 5+ years old compiler, you really do not care about performance, something Eigen uses generally care about. So you are not in a targeted user group of Eigen. Little HPC clusters do not at all offer any way to install a more recent compilers that 5 years (this has changed a lot from a decade ago) and even in the embedded world, vendors tend to drop support or upgrade for platforms with more than 5 years old toolchains too (this has also very much changed from 10 years ago). Eigen users should be able to get a clear answer on the question when we drop C++98 (of if). That belongs on the front page IMHO. Kind regards, Martin
