|Re: [eigen] About dropping C++03 compatibility|
[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]
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.htmlThat'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.
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,PatrikOn Wed, 20 Feb 2019 at 16:58, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:On Wed, Feb 20, 2019 at 3:52 PM Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> 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-17and after moving to C++14: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.
Dr.-Ing. Christoph Hertzberg
Besuchsadresse der Nebengeschäftsstelle:
Robotics Innovation Center
28359 Bremen, Germany
Postadresse der Hauptgeschäftsstelle Standort Bremen:
Robotics Innovation Center
28359 Bremen, Germany
Tel.: +49 421 178 45-4021
Zentrale: +49 421 178 45-0
Weitere Informationen: http://www.dfki.de/robotik
Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany
Prof. Dr. Jana Koehler (Vorsitzende)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
|Mail converted by MHonArc 2.6.19+||http://listengine.tuxfamily.org/|