[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- (https: //eigen.tuxfamily.org/dox/group__TopicStructHavingEigenMembers.html)
- Https: //eigen.tuxfamily.org/dox/group__TopicStlContainers.html).
If this is possible in the current branch, without losing C++03 support,
yes of course that's the better option (and as a user I don't care about
how "nice" or "ugly" Eigen implements this internally), I completely agree
with David there.
But if such a thing would not be possible without unconditionally moving to
C++17 (or 14), then this would be in my opinion exactly a very strong case
to move to a newer standard version, because it's not about Eigen's
internal implementation, but would fix/improve a serious gotcha for many
consumers of Eigen.
I see actually there has been some activity in the related bug report (
http://eigen.tuxfamily.org/bz/show_bug.cgi?id=3D1409) today, and it might b=
e
possible to do it conditionally in the current Eigen branch, if the user
has C++17 enabled. That would be awesome.
(On a side note, I'm subscribed to that bug report's CC list but didn't get
any update emails about it today.)
Best regards,
Patrik
On Tue, 19 Feb 2019 at 21:23, David Tellenbach <
david.tellenbach@xxxxxxxxxxxxx> wrote:
> 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 interna=
ls
> 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 fo=
r
> some features in the core module. The reason why I originally asked about
> newer standards was the discussion about the plain keyword Ga=C3=ABl 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 wit=
h
> 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 lik=
e
> 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=3D4.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 Eige=
n
> 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 n=
ew
> 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 n=
ew
> 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 base=
d
> 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 bas=
e,
> 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=C3=A4ftsstelle:
> > DFKI GmbH
> > Robotics Innovation Center
> > Robert-Hooke-Stra=C3=9Fe 5
> > 28359 Bremen, Germany
> >
> > Postadresse der Hauptgesch=C3=A4ftsstelle Standort Bremen:
> > DFKI GmbH
> > Robotics Innovation Center
> > Robert-Hooke-Stra=C3=9Fe 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=C3=BCr K=C3=BCnstliche Intelligenz GmbH
> > Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany
> >
> > Gesch=C3=A4ftsf=C3=BChrung:
> > Prof. Dr. Jana Koehler (Vorsitzende)
> > Dr. Walter Olthoff
> >
> > Vorsitzender des Aufsichtsrats:
> > Prof. Dr. h.c. Hans A. Aukes
> > Amtsgericht Kaiserslautern, HRB 2313
> > -------------------------------------------------------------
> >
> >
> >
>
>
>
>
--000000000000cb390f0582463b2e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi all,</div><div><br></div>From a user's perspec=
tive, one of the main things that I think would be *really* good to get rid=
of is the need for EIGEN_MAKE_ALIGNED_OPERATOR_NEW (<a href=3D"https://eig=
en.tuxfamily.org/dox/group__TopicStructHavingEigenMembers.html">https://eig=
en.tuxfamily.org/dox/group__TopicStructHavingEigenMembers.html</a>) and the=
allocator stuff (<a href=3D"https://eigen.tuxfamily.org/dox/group__TopicSt=
lContainers.html">https://eigen.tuxfamily.org/dox/group__TopicStlContainers=
..html</a>).<br>In my opinion this is a very serious "gotcha" for =
the average (and even more advanced) Eigen users, let alone beginners. It&#=
39;s very unintuitive to have to think about this, and I have no numbers to=
back this up, but I would guess that you'll find tons of code in the w=
ild that should use those macros/allocators but don't, just because the=
y don't know about it. It's also quite invasive to "have to&qu=
ot; put these things into my code.<br><br>If this is possible in the curren=
t branch, without losing C++03 support, yes of course that's the better=
option (and as a user I don't care about how "nice" or "=
;ugly" Eigen implements this internally), I completely agree with Davi=
d there.<br>But if such a thing would not be possible without unconditional=
ly moving to C++17 (or 14), then this would be in my opinion exactly a very=
strong case to move to a newer standard version, because it's not abou=
t Eigen's internal implementation, but would fix/improve a serious gotc=
ha for many consumers of Eigen.<br><br>I see actually there has been some a=
ctivity in the related bug report (<a href=3D"http://eigen.tuxfamily.org/bz=
/show_bug.cgi?id=3D1409">http://eigen.tuxfamily.org/bz/show_bug.cgi?id=3D14=
09</a>) today, and it might be possible to do it conditionally in the curre=
nt Eigen branch, if the user has C++17 enabled. That would be awesome.<br><=
br>(On a side note, I'm subscribed to that bug report's CC list but=
didn't get any update emails about it today.)<div><br></div><div>Best =
regards,</div><div>Patrik</div></div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr" class=3D"gmail_attr">On Tue, 19 Feb 2019 at 21:23, David Tellenba=
ch <<a href=3D"mailto:david.tellenbach@xxxxxxxxxxxxx";>david.tellenbach@t=
ellnotes.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">Hello together,<br>
<br>
I completely agree with Christoph.<br>
<br>
The fact that Eigen 3.x is C++03 compatible does *not* mean that Eigen user=
s can't use C++11/14/17 features in their code. Sure, newer features co=
uld improve some internal parts but excluding users for fancier internals i=
s most likely a bad idea.<br>
<br>
Public features and the API are a different story but as mentioned by Chris=
toph 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=C3=ABl had in mind,=
which would need at least C++17 support (correct me if I'm wrong). <br=
>
<br>
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.<br>
<br>
The compatibility of Eigen 4 (whenever this will happen and whatever standa=
rd exists then) is something we should discuss then.<br>
<br>
Regards,<br>
David<br>
<br>
<br>
> On 19. Feb 2019, at 19:26, Christoph Hertzberg <<a href=3D"mailto:c=
htz@xxxxxxxxxxxxxxxxxxxxxxxx" target=3D"_blank">chtz@xxxxxxxxxxxxxx-bremen.=
de</a>> wrote:<br>
> <br>
> Hi!<br>
> <br>
> About Eigen 4.0, there are currently no plans nor anything remotely li=
ke 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:<br>
> <a href=3D"http://eigen.tuxfamily.org/bz/show_bug.cgi?id=3D4.0"; rel=3D=
"noreferrer" target=3D"_blank">http://eigen.tuxfamily.org/bz/show_bug.cgi?i=
d=3D4.0</a><br>
> So any decision on which standard we want to require for 4.0 is very h=
ypothetical at the moment (by that time C++17 could be completely outdated)=
..<br>
> <br>
> <br>
> Regarding 3.4/3.5/...<br>
> Increasing the required standard to compile Eigen could simplify maint=
enance in the long run, but will not have any measurable impact for users o=
f Eigen (except *maybe* better compile times, although several new features=
will more likely increase compile times).<br>
> 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.<br>
> <br>
> But, at the moment, increasing the minimal standard for Eigen 3.4 woul=
d 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 su=
pport. Also, so far we (almost) only backported bugfixes to 3.3 and introdu=
ced new features only to the development branch (that is kind of the idea o=
f 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).<br>
> <br>
> <br>
> Cheers,<br>
> Christoph<br>
> <br>
> <br>
> On 19/02/2019 18.41, Michael Hofmann wrote:<br>
>> Indeed, I completely agree that it's time to bring Eigen into =
the<br>
>> second half of the 2010s.<br>
>> Quoting Patrik Huber:<br>
>>> (...) 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.<br>
>> I share the opinion that for another major release (Eigen 4), ther=
e<br>
>> should be a considerable leap in required C++ standard, and I argu=
e<br>
>> this should be C++17.<br>
>> Eigen 3.4 will of course still be C++03 compatible, and remain<br>
>> available! So I do not see any concerns related to making a bigger=
<br>
>> leap.<br>
>> Requiring C++14 should be the minimum for a new major version, but=
<br>
>> staying there feels a bit stagnant to me, given that it's 2019=
and<br>
>> C++20 is well on the horizon.<br>
>> Why C++17? Like another poster before me, I strongly suspect that =
a<br>
>> lot of code can be considerably simplified by judicious use of =
9;if<br>
>> constexpr'. Both C++14 and 17 have brought improvements in han=
dling<br>
>> aligned memory, so some of the Eigen macros will likely not be nee=
ded<br>
>> anymore. Variable templates (i.e. sth. like is_same_v<>) can=
help<br>
>> unclutter a lot of Eigen and user code (removing the need for<br>
>> 'typename .....::type' in many places). I am quite sure th=
ere will be<br>
>> good use cases for fold expressions in Eigen.<br>
>> And so on. In my experience, C++ is a noticeable improvement over<=
br>
>> C++14 for library writers. I would not want to go back, and I'=
m<br>
>> expecting more and more libraries to follow suit these days, to st=
ay<br>
>> relevant and well maintained.<br>
>> C++17 is well supported by Clang 5+, GCC8+ (many features already =
in<br>
>> GCC7), and VS2017. A fewexceptions still apply, like std::pmr, or<=
br>
>> parallel STL, which are expected soon in GCC9/Clang 8. There shoul=
dn't<br>
>> be any ABI changes in implementation between C++11 and 17, so &quo=
t;getting<br>
>> the entire ecosystem recompiled", a previously expressed conc=
ern,<br>
>> should not be necessary.<br>
>> Regards,<br>
>> Michael<br>
>> On Tue, Feb 19, 2019 at 3:23 PM Peter <<a href=3D"mailto:list@s=
chmitteckert.com" target=3D"_blank">list@xxxxxxxxxxxxxxxxx</a>> wrote:<b=
r>
>>> <br>
>>> Hi,<br>
>>> <br>
>>> <br>
>>> Am 19.02.19 um 14:58 schrieb Gael Guennebaud:> Hi,<br>
>>>=C2=A0 ><br>
>>>=C2=A0 > this a follow-up of another thread that deviated to=
wards the question of what should be the minimal c++ version required for f=
uture Eigen's version.<br>
>>>=C2=A0 ><br>
>>>=C2=A0 > Just to be clear, the 3.4 version will be fully com=
patible with C++03, while exposing/taking-advantage-of a few C++11, C++14, =
and even C++17 features when available.<br>
>>>=C2=A0 ><br>
>>>=C2=A0 > There is, however, a limit in conditionally enablin=
g features based on the available c++ version, and maintaining multiple var=
iants is out of reach for us.<br>
>>>=C2=A0 ><br>
>>>=C2=A0 > 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.<br>
>>> <br>
>>> I would vote for C++14 for a 4.x release.<br>
>>> In my opinion it's a good reason to switch if that helps t=
o speed up Eigen's code development.<br>
>>> <br>
>>> Switching to C++14 for a 4.x release won't magically destr=
oy the 3.4 release.<br>
>>> Projects which depend on older infra structure (e.g. some HPC =
platforms tend to be<br>
>>> rather out-dated) can still use the 3.4 release.<br>
>>> <br>
>>> <br>
>>> Best regards,<br>
>>> Peter<br>
>>> <br>
>>> <br>
>>> <br>
>>> <br>
> <br>
> -- <br>
> Dr.-Ing. Christoph Hertzberg<br>
> <br>
> Besuchsadresse der Nebengesch=C3=A4ftsstelle:<br>
> DFKI GmbH<br>
> Robotics Innovation Center<br>
> Robert-Hooke-Stra=C3=9Fe 5<br>
> 28359 Bremen, Germany<br>
> <br>
> Postadresse der Hauptgesch=C3=A4ftsstelle Standort Bremen:<br>
> DFKI GmbH<br>
> Robotics Innovation Center<br>
> Robert-Hooke-Stra=C3=9Fe 1<br>
> 28359 Bremen, Germany<br>
> <br>
> Tel.:=C2=A0 =C2=A0 =C2=A0+49 421 178 45-4021<br>
> Zentrale: +49 421 178 45-0<br>
> E-Mail:=C2=A0 =C2=A0<a href=3D"mailto:christoph.hertzberg@xxxxxxx"; tar=
get=3D"_blank">christoph.hertzberg@xxxxxxx</a><br>
> <br>
> Weitere Informationen: <a href=3D"http://www.dfki.de/robotik"; rel=3D"n=
oreferrer" target=3D"_blank">http://www.dfki.de/robotik</a><br>
>=C2=A0 -------------------------------------------------------------<br=
>
>=C2=A0 Deutsches Forschungszentrum f=C3=BCr K=C3=BCnstliche Intelligenz=
GmbH<br>
>=C2=A0 Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany<br>
> <br>
>=C2=A0 Gesch=C3=A4ftsf=C3=BChrung:<br>
>=C2=A0 Prof. Dr. Jana Koehler (Vorsitzende)<br>
>=C2=A0 Dr. Walter Olthoff<br>
> <br>
>=C2=A0 Vorsitzender des Aufsichtsrats:<br>
>=C2=A0 Prof. Dr. h.c. Hans A. Aukes<br>
>=C2=A0 Amtsgericht Kaiserslautern, HRB 2313<br>
>=C2=A0 -------------------------------------------------------------<br=
>
> <br>
> <br>
> <br>
<br>
<br>
<br>
</blockquote></div>
--000000000000cb390f0582463b2e--