1 - There is absolutely no reason to assume it would. 2 - I would be *very* unhappy happy if Eigen did try to keep support for such ancient compilers for any new major release. By all means, let's confidently move into the future (or rather present: C++17). As already mentioned, existing releases can still be used with such old toolchains. Also, it's not difficult to install a recent compiler.
Best, Michael On Fri, Mar 15, 2019, 4:57 PM William Tambellini <[email protected]> wrote: > I would nt mind eigen to move to C++11 but just to check : > > 1- it would nt imply any perf drop ? > > 2- it would keep compatibility with the default centos7 gcc aka gcc 4.8.5 ? > W. > > > ------------------------------ > *From:* Rasmus Munk Larsen <[email protected]> > *Sent:* Friday, February 22, 2019 11:18:26 AM > *To:* eigen > *Subject:* Re: [eigen] About dropping C++03 compatibility > > BTW: Regarding language standards, we at Google would be ecstatic if Eigen > moved to c++11 or beyond. > > On Wed, Feb 20, 2019 at 11:11 AM Rasmus Munk Larsen <[email protected]> > wrote: > > > > On Wed, Feb 20, 2019 at 10:39 AM Patrik Huber <[email protected]> > wrote: > > Hi Gael / all, > > >> 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. > >> As of today, this is also conditionally removed from Eigen's classes > and, more importantly, documented: > http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html > > That's awesome! Thank you a lot for this, that's a great change and a > serious gotcha removed from Eigen. > > >> Recall that Eigen is developed on spare time. > > I apologise, I think that my sentence in the parentheses came across wrong > and you may have misunderstood my intention. I understand Eigen is mainly > developed in people's spare time and I am very grateful to everyone. > What I meant was what Christoph said, that I thought I should get emails > from the bugtracker if I'm on the CC list, but I haven't received those > automated update emails from the bugtracker. Now that Christoph mentioned > it again, I remember I actually logged this bug last year ( > http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1640) and it is indeed > misconfigured SPF (which would affect not only gmail but all/most spam > filters, gmail just seems more aggressive). Indeed I found those emails in > the Spam folder, thanks Christoph for reminding me. > > > On the note of developing/contributing to Eigen, I wholeheartedly agree > with what Michael said earlier in this thread. More people might be > inclined to contribute to Eigen, if the project moves forward a bit instead > of keeping tons of old cruft. Agree with Christoph that Eigen will always > be complex code, but there's different levels of complex. I would actually > be quite a bit concerned about the future / long-term survival of Eigen. > How many people are significantly and actively contributing? I can only > name Gael and Christoph (the bitbucket commit log shows a few others but > with rather small commits, focused on some specific areas). So the "truck > factor" of Eigen might pretty much be 2? Which is quite concerning, given > that Eigen very likely powers a very significant portion of today's world, > from AI, robots, to possibly things like space travel or even nuclear power > plants. I wonder why there's not more of the big companies allowing > employees to dedicate some of their paid work time to Eigen. > > > Just for the record: I work for Google, in the TensorFlow team, and part > of my job is to help maintain Eigen and the many many (literally millions) > of build targets that depend on it across the Alphabet companies. As you > say, Eigen is used widely for AI, machine learning, mobile, AR/VR, > robotics, signal processing etc. and really in most places where numerical > computation in C++ is needed. We are very grateful for the efforts of the > Eigen maintainers and the community and are committed to continue our > support for a free and open Eigen library. > > > > Anyway, moving to C++14/17 will certainly not suddenly improve all that > but I can only say I so much agree with what Michael said. > > > With regards to C++ standards usage / survey, the JetBrains developer > survey might be interesting too: > https://www.jetbrains.com/research/devecosystem-2018/cpp/ > It's from Jan 2018, so the numbers are a bit dated now, but the 2019 > survey should come out in a few weeks or so I guess. And I think doing our > own small survey would be a great idea. > > Best, > Patrik > > > On Wed, 20 Feb 2019 at 16:58, Gael Guennebaud <[email protected]> > wrote: > > > > On Wed, Feb 20, 2019 at 3:52 PM Christoph Hertzberg < > [email protected]> wrote: > > > > On 20/02/2019 08.04, Michael Hofmann wrote: > > [...] > > > > If you want a motivated base of people *maintaining and contributing > > to* Eigen, by all means, get the Eigen codebase modernized and greatly > > simplified in the progress! It makes a big difference. > > And it does seem to me that Eigen could use a more active community > > working on it. My personal impression of Eigen certainly has changed a > > bit in the last few years, as these obvious modernization tasks are > > not even attempted. > > "Simplifying" the codebase by using C++14/17 would for many parts > essentially mean to rewrite them --> _May_ save work in the long run, > but not feasible or worth the effort for now. > Large parts of Eigen are complicated regardless of the standard we use. > > > without rewriting everything, many new features, bug fixes and > improvements could have been implemented much more rapidly if c++11/14 > could be used without bothering about c++03. > #if CXX11 guards are perfectly fine when the goal is to expose a specific > feature that only exist with CPP11 and that does not interact with the rest > of Eigen's code base. But for all other cases #if guards just make > everything even more complicated. > > Just one example, look at this mess: > > > https://bitbucket.org/eigen/eigen/src/fed0f93f7118b9eae028c9342ed5e3d7a735b17f/Eigen/src/Core/ArithmeticSequence.h#lines-17 > > and after moving to C++14: > > https://pastebin.com/KWNfzdXJ > <http://webdefence.global.blackspider.com/urlwrap/?q=AXicY2Rm8FrCwHB9AQNDUU6lkVmiXnFRmV5uYmZOcn5eSVF-jl5yfi5DhaGvl1ehpYuBgamhoRlDeUliblJqTk5mXqZDcQpESUZJSUGxlb5-QWJxSWpSZh5IUN873C-tKiXCi4GBoXMKAwMAhsojLw&Z> > > Believe me, I really don't want to make any additional change to > ArithmeticSequence without cleaning it first! > > > > I have to admit I do not understand conservativism around moving a > > codebase along with the times. As someone else said before in this > > thread, older releases do not magically disappear! Anyone can still > > use them. > > It is also an issue of having to maintain code bases which largely > diverged. Currently, many bug fixes can simply be grafted to the 3.3 > branch. > > > yes, that's a real concerns I had too. So let's make 3.4 super robust ;) > > > > Without having data to back this up, [...] > > Perhaps we should conduct some kind of survey about > * Which Eigen versions are currently used (3.1??, 3.2, 3.3, default) > * What CPU/OS/Compiler/C++-standard/... > * What modules of Eigen/what kind of problems/... > * Most concerning issues/wanted features/... > * ... > > Anyone willing to collect questions and set this up? (Maybe start > brainstorming questions in a new mail-thread) > > > It would be very nice if someone would set this up! I'd advise to keep the > survey as short as possible with a focus on questions for which we really > have no clue and of interest for the evolution of Eigen. For instance, the > results on CPU/OS are very predictable and of little use IMO. On the other > hand the compiler versions and maximal c++ versions (today and expected > within, say, 3 years) are of utmost importance. > > gael. > > > > > > > Christoph > > > > > -- > 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: [email protected] > > 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 > ------------------------------------------------------------- > > > > > > Click here > <https://www.mailcontrol.com/sr/0JYxv2ScOhHGX2PQPOmvUg5_3elP1qzzbnG4d_r1EP0iIm7trXtadBT4t_0XItBgMEtsjCueQ7weq4Nrivo6iw==> > to report this email as spam. >
