Re: [eigen] About dropping C++03 compatibility

[ Thread Index | Date Index | More Archives ]


About Eigen 4.0, there are currently no plans nor anything remotely like a schedule for that. All we currently have is a meta-bug to collect API changes which we don't want to do for 3.x:
So any decision on which standard we want to require for 4.0 is very hypothetical at the moment (by that time C++17 could be completely outdated).

Regarding 3.4/3.5/...
Increasing the required standard to compile Eigen could simplify maintenance in the long run, but will not have any measurable impact for users of Eigen (except *maybe* better compile times, although several new features will more likely increase compile times). We already have one module (the Tensor module) which mostly depends on C++11, i.e., development in there can use "modern" (only 8 year old, instead of 20 year old ^^) C++. If, in the future, we add further new modules which are unreasonably complicated to implement without C++14/17/... we can of course make them require that standard.

But, at the moment, increasing the minimal standard for Eigen 3.4 would essentially mean that we'd need to maintain Eigen 3.3 in parallel to Eigen 3.4 or lose several users that still don't have reliable C++11 support. Also, so far we (almost) only backported bugfixes to 3.3 and introduced new features only to the development branch (that is kind of the idea of a stable branch). But there should be no need to exclude "old" users from new features (if implementing the feature does not require more than C++03).


On 19/02/2019 18.41, Michael Hofmann wrote:
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
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.


On Tue, Feb 19, 2019 at 3:23 PM Peter <list@xxxxxxxxxxxxxxxxx> wrote:


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,

 Dr.-Ing. Christoph Hertzberg

 Besuchsadresse der Nebengeschäftsstelle:
 Robotics Innovation Center
 Robert-Hooke-Straße 5
 28359 Bremen, Germany

 Postadresse der Hauptgeschäftsstelle Standort Bremen:
 Robotics Innovation Center
 Robert-Hooke-Straße 1
 28359 Bremen, Germany

 Tel.:     +49 421 178 45-4021
 Zentrale: +49 421 178 45-0
 E-Mail:   christoph.hertzberg@xxxxxxx

 Weitere Informationen:
  Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
  Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany

  Prof. Dr. Jana Koehler (Vorsitzende)
  Dr. Walter Olthoff

  Vorsitzender des Aufsichtsrats:
  Prof. Dr. h.c. Hans A. Aukes
  Amtsgericht Kaiserslautern, HRB 2313

Mail converted by MHonArc 2.6.19+