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

[Martin Beeger <martin.beeger@xxxxxxxxx>]

Hey list!

I second that there should be a major leap in the minimally required
version for 4.x.
It is possible to drastically improve compile times and code clarity
with newer C++ versions. Especially the algiment function which make
eigen macros unnecessary are very promising.
I would argue to not completely jump over the C++14 and directly go to
17 though, at least not if the release timeline is within a year.
C++17 ist not avavilable readily in wide parts of the embedded world and
will not be for at least 1 year. Currently not even the the compilers in
my desktop linux are recent enough to support it. If any user needs to
compile its own compiler to use Eigen, a huge part of the ease and
pleasure Eigens use and deployment currently is will turn into a
nightmare, at least in the short term.
If we plan do have the 4.x development branch around for a year at least
anyway, then building on top of C++17 is most likely fine.

Martin

Am 19.02.19 um 18:41 schrieb Michael Hofmann:
> 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
>>
>>
>>
>>
>