Indeed, I completely agree that it's time to bring Eigen into the
second half of the 2010s.
Quoting Patrik Huber:
(...) in my opinion it would be a real back-step if the "hypothetical" Eigen 4 was stuck on C++11. I would very strongly argue to at least make the step to full C++14 and potentially C++17.
I share the opinion that for another major release (Eigen 4), there
should be a considerable leap in required C++ standard, and I argue
this should be C++17.
Eigen 3.4 will of course still be C++03 compatible, and remain
available! So I do not see any concerns related to making a bigger
leap.
Requiring C++14 should be the minimum for a new major version, but
staying there feels a bit stagnant to me, given that it's 2019 and
C++20 is well on the horizon.
Why C++17? Like another poster before me, I strongly suspect that a
lot of code can be considerably simplified by judicious use of 'if
constexpr'. Both C++14 and 17 have brought improvements in handling
aligned memory, so some of the Eigen macros will likely not be needed
anymore. Variable templates (i.e. sth. like is_same_v<>) can help
unclutter a lot of Eigen and user code (removing the need for
'typename .....::type' in many places). I am quite sure there will be
good use cases for fold expressions in Eigen.
And so on. In my experience, C++ is a noticeable improvement over
C++14 for library writers. I would not want to go back, and I'm
expecting more and more libraries to follow suit these days, to stay
relevant and well maintained.
C++17 is well supported by Clang 5+, GCC8+ (many features already in
GCC7), and VS2017. A fewexceptions still apply, like std::pmr, or
parallel STL, which are expected soon in GCC9/Clang 8. There shouldn't
be any ABI changes in implementation between C++11 and 17, so "getting
the entire ecosystem recompiled", a previously expressed concern,
should not be necessary.
Regards,
Michael
On Tue, Feb 19, 2019 at 3:23 PM Peter <list@xxxxxxxxxxxxxxxxx> wrote:
Hi,
Am 19.02.19 um 14:58 schrieb Gael Guennebaud:> Hi,
>
> this a follow-up of another thread that deviated towards the question of what should be the minimal c++ version required for future Eigen's version.
>
> Just to be clear, the 3.4 version will be fully compatible with C++03, while exposing/taking-advantage-of a few C++11, C++14, and even C++17 features when available.
>
> There is, however, a limit in conditionally enabling features based on the available c++ version, and maintaining multiple variants is out of reach for us.
>
> Moreover, switching to c++11 or even 14 would help *a lot* in day-to-days Eigen coding with many opportunities to simplify the code base, logics, compilation-times, unit-testing, etc.
I would vote for C++14 for a 4.x release.
In my opinion it's a good reason to switch if that helps to speed up Eigen's code development.
Switching to C++14 for a 4.x release won't magically destroy the 3.4 release.
Projects which depend on older infra structure (e.g. some HPC platforms tend to be
rather out-dated) can still use the 3.4 release.
Best regards,
Peter