I was rather thinking about upgrading to C++11/14 while keeping API compatibility with 3.4, so that would be for Eigen 3.5. Moving to c++17 only is definitely not option, but C++14 seems doable to me. C++14 is required if we want to properly handle scalar types with _expression_ template.
A key question is rather how many users will still be stuck to C++03 by the time of 3.5, say 2021? There are more than 700 members on this list, so we should quickly know if the ratio is larger or lower than ~0.1%. For a more thorough measure, we could make a little survey while releasing 3.4.
Gaël.
Hi!
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:
http://eigen.tuxfamily.org/bz/show_bug.cgi?id=4..0
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).
Cheers,
Christoph
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
> 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
>>
>>
>>
>>
>
>
>
--
Dr.-Ing. Christoph Hertzberg
Besuchsadresse der Nebengeschäftsstelle:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany
Postadresse der Hauptgeschäftsstelle Standort Bremen:
DFKI GmbH
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: http://www.dfki.de/robotik
-------------------------------------------------------------
Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany
Geschäftsführung:
Prof. Dr. Jana Koehler (Vorsitzende)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
-------------------------------------------------------------