| Re: [eigen] Taking advantage of C++11 features in Eigen |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
On 12.02.2014 15:43, Nicola Gigante wrote:
Il giorno 12/feb/2014, alle ore 12:44, Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> ha scritto:
On 11.02.2014 20:54, Nicola Gigante wrote:
I’m recently starting to follow the Eigen project and I was wondering which is the current status
of C++11 features support inside the library. It seems the library is “compatible” with C++11,
meaning that it compiles and works properly with the new standard, but does not take
advantage of new features when available.
Generally, we want to keep Eigen C++03 compatible as much as possible. There are C++11 things implemented which don't jeopardize that, like move semantics.
https://bitbucket.org/eigen/eigen/src/90f8b868e6e2/Eigen/src/Core/Matrix.h?at=default#cl-220
Glad to see that move certain types already have move constructors. I should have looked better at it but the online doc is from the
stable branch...
Yes, this is only in the devel-branch and it lacks doxygen
documentation. Unfortunately, especially for internal things of Eigen
you need to study the source code (this has been pending for a while
http://eigen.tuxfamily.org/bz/show_bug.cgi?id=138 ...)
http://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2013/11/msg00000.html
I don’t agree very much on that. Switch to C++11 is a well-thought choice for users. First of all, it’s opt-in from the compiler
point of view. You have to explicitly tell the compiler to compile in C++11 mode. You just don’t “happen” to be using a C++11
feature without knowing it. Then when one decides to use C++11 in his project, it’s not only a matter of new syntactic sugar or better
performance. It has a broad impact on the entire design of an application or library, especially on new projects. I think
a useful feature shouldn’t be avoided just because the user might have troubles converting _its own_ code to not use it anymore.
Okay, maybe my concern is a bit far-fetched. Consider this scenario:
A user has a compiler which enables C++11 (or his build system
accidentally does). He writes a library which depends on Eigen and
claims to be C++03 compatible, since Eigen is and he did not knowingly
use C++11 features himself. He then releases his library and gets
complaints from users without or with insufficient C++11 support.
Even when only using the code by oneself, I myself had my experiences
with compiling on different machines having different compiler versions
(actually, my problems were more on different versions of an OS-provided
library, but I think this somewhat similar).
Generally, this is not an argument against introducing C++11 features in
Eigen, but to properly protecting against "accidentally" using them.
I.e., if a user makes a well-thought decision to switch to C++11 he
shall be able to do so (and profit from it), but not complain if he
later needs to port his code to a system with inferior compiler support.
You can make the choice even more explicit if you want, by testing a EIGEN_USE_CPP11 symbol or something like that.
We decided against further user provided preprocessor symbols (we had
some troubles with EIGEN_DEFAULT_TO_ROW_MAJOR in the past
http://eigen.tuxfamily.org/bz/show_bug.cgi?id=422 -- again, maybe I'm
over-concerned here ...)
What other libraries are doing is to conditionally support such features if explicitly enabled and supported by the compiler,
and silently drop them if missing. From the users point of view is clean, painless, and enables them to choose how to write their code.
Basically, that is the plan for Eigen as well (as far as I interpreted
our previous discussions about it). Only we decided to enable features
by including files from <Eigen/CXX11/...> instead of using preprocessor
defines. If you have good arguments for the latter approach, it would
not be too late yet to change that decision (so far we mostly have one
unsupported module depending on C++11).
If yours is not a firm stop sign, I would like to start working on some ideas and, as time goes, we can see if they're worth or not.
I definitely don't want to stop you entirely from providing C++11
features to Eigen (nor would I consider to have anything near the right
to solitarily keep you from doing it).
I guess I mostly was a bit worried by your first mail that your plans
would endanger C++03 compatibility/maintainability ...
Sorry for skipping most of your mail. Generally, I agree that C++11 adds
a lot of very useful extensions, which we eventually shall use in Eigen.
For details, maybe C++11 experts want to join the discussion ...
Christoph
--
----------------------------------------------
Dipl.-Inf., Dipl.-Math. Christoph Hertzberg
Cartesium 0.049
Universität Bremen
Enrique-Schmidt-Straße 5
28359 Bremen
Tel: +49 (421) 218-64252
----------------------------------------------