New user self-registration is currently disabled. Please email eigen-core-team @ lists.tuxfamily.org if you need an account.
Bug 266 - std::move support for Matrix/Array
std::move support for Matrix/Array
Status: RESOLVED FIXED
Product: Eigen
Classification: Unclassified
Component: Core - general
3.2
All All
: --- enhancement
Assigned To: Hauke Heibel
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-12 21:15 UTC by Hauke Heibel
Modified: 2015-10-21 12:48 UTC (History)
7 users (show)



Attachments
Enables std::move support on Matrix, Array and a minimal set of required classes. (8.94 KB, patch)
2011-05-12 21:15 UTC, Hauke Heibel
hauke.heibel: review+
Details | Diff

Description Hauke Heibel 2011-05-12 21:15:32 UTC
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
Comment 1 Benjamin Piwowarski 2012-05-24 09:38:43 UTC
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
Comment 2 Martin Drozdik 2014-02-03 02:03:46 UTC
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
Comment 3 Martin Drozdik 2014-02-03 02:17:31 UTC
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
Comment 4 Christoph Hertzberg 2014-02-03 03:19:42 UTC
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
Comment 5 Roman Werpachowski 2015-10-18 10:27:57 UTC
It would be great if this patch went in version 3.2.
Comment 6 Gael Guennebaud 2015-10-21 12:48:43 UTC
Backported as changeset 4fdf206720c9.

Note You need to log in before you can comment on or make changes to this bug.