Summary: | std::move support for Matrix/Array | ||||||
---|---|---|---|---|---|---|---|
Product: | Eigen | Reporter: | Hauke Heibel <hauke.heibel> | ||||
Component: | Core - general | Assignee: | Hauke Heibel <hauke.heibel> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | enhancement | CC: | benjamin, chtz, drozdik.svk, gael.guennebaud, jacob.benoit.1, megabyte, roman.werpachowski | ||||
Priority: | --- | ||||||
Version: | 3.2 | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Whiteboard: | |||||||
Attachments: |
|
Hi, You have forgotten about SparseMatrix, here is the code to be inserted in #ifdef EIGEN_HAVE_CXX0X SparseMatrix(SparseMatrix &&other) : Base(), m_outerSize(-1), m_innerSize(0), m_outerIndex(0), m_innerNonZeros(0) { check_template_parameters(); resize(0, 0); this->swap(other); } SparseMatrix &operator=(SparseMatrix &&other) { this->swap(other); return *this; } #endif Another thing: I would change the macro to EIGEN_HAS_MOVE since move is not supported by any C++0x or C++11 compiler (example: clang with libstdc++ instead of libc++); we can also add a condition on __cplusplus that is more "standard" # if (__cplusplus >= 201103L) || defined(__GXX_EXPERIMENTAL_CXX0X__) || (defined(_MSC_VER) && (_MSC_VER >= 1600)) # if !(defined(__clang__) && defined(__GLIBCXX__)) # define EIGEN_HAS_MOVE # endif # endif Hello, I would like to ask if this patch will make it to a release version anytime soon. I know that Eigen uses expression templates to avoid creation of expensive objects in most cases, but the proposed move constructors and move assignment operators seem like a great improvement. Consider the case that you have a std::vector<Eigen::VectorXd> vec; and you want to sort this vector using a sorting algorithm which does not use std::swap but something else. Soon you end with a performance problem. Is there anything holding this patch back? In case it does not make it to a release version, how can I apply it to my Eigen 3.2.0 version? Are there any known risks? I also asked this question on Stack Overflow, http://stackoverflow.com/questions/21503220/how-to-enable-copy-eliding-move-members-for-eigen-vectors so if you answer there, more people will know about the issue. kind regards Martin Hello, I would like to ask if this patch will make it to a release version anytime soon. I know that Eigen uses expression templates to avoid creation of expensive objects in most cases, but the proposed move constructors and move assignment operators seem like a great improvement. Consider the case that you have a std::vector<Eigen::VectorXd> vec; and you want to sort this vector using a sorting algorithm which does not use std::swap but something else. Soon you end with a performance problem. Is there anything holding this patch back? In case it does not make it to a release version, how can I apply it to my Eigen 3.2.0 version? Are there any known risks? I also asked this question on Stack Overflow, http://stackoverflow.com/questions/21503220/how-to-enable-copy-eliding-move-members-for-eigen-vectors so if you answer there, more people will know about the issue. kind regards Martin Basically, the functionality has been implemented in the devel-branch here: https://bitbucket.org/eigen/eigen/commits/c280e906ade The 3.2 branch will mostly just get bug-fixing commits. If changing to the dev-branch (or waiting for 3.3) is not an option for you, you could try transplanting the commit I mentioned to your 3.2 version (I think the main difference to attachment 170 [details] is a more conservative recognition of C++11 availability). Actually, I don't see much risk in committing it to 3.2 so it might make it into 3.2.1 It would be great if this patch went in version 3.2. Backported as changeset 4fdf206720c9. -- GitLab Migration Automatic Message -- This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/266. |
Created attachment 170 [details] Enables std::move support on Matrix, Array and a minimal set of required classes. I have send this already to the list. With the attached patch, I enable r-value constructors in Array, Matrix and a few related classes such that PlainObjects are now std::move enabled. This means, that in C++0x environment dynamic Matrix and Array objects could be returned from any function by value without triggering a copy in an assignment. Here is an example: MatrixXd square(const MatrixXd& m) { return m*m; } MatrixXd m2 = square( MatrixXd::Random(500,500) ); During this assignment we could be sure that no additional temporary is created without the need of ReturnByValue. I think this feature would be really great since it would allow users to benefit from new language features without the need of tricky constructs such as ReturnByValue. - Hauke