I see actually there has been some activity in the related bug report (
http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1409) today, and it might be possible to do it conditionally in the current Eigen branch, if the user has C++17 enabled. That would be awesome.
this is off topic but with c++17 and gcc 7+ or clang 7+ and the head of Eigen, it was already possible to get rid of EIGEN_MAKE_ALIGNED_OPERATOR_NEW in user code.
(On a side note, I'm subscribed to that bug report's CC list but didn't get any update emails about it today.)
Recall that Eigen is developed on spare time.
cheers,
Gaël.
Hello together,
I completely agree with Christoph.
The fact that Eigen 3.x is C++03 compatible does *not* mean that Eigen users can't use C++11/14/17 features in their code. Sure, newer features could improve some internal parts but excluding users for fancier internals is most likely a bad idea.
Public features and the API are a different story but as mentioned by Christoph there are even whole modules requiring C++11. The same holds for some features in the core module. The reason why I originally asked about newer standards was the discussion about the plain keyword Gaël had in mind, which would need at least C++17 support (correct me if I'm wrong).
So I guess the best way for Eigen 3.x is to guard newer functionality with EIGEN_HAS_CXXYY as we already did for C++11 and (in some rare cases) for C++14.
The compatibility of Eigen 4 (whenever this will happen and whatever standard exists then) is something we should discuss then.
Regards,
David
> On 19. Feb 2019, at 19:26, Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> 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
> -------------------------------------------------------------
>
>
>