This bugzilla service is closed. All entries have been migrated to https://gitlab.com/libeigen/eigen
Bug 266 - std::move support for Matrix/Array
Summary: std::move support for Matrix/Array
Status: RESOLVED FIXED
Alias: None
Product: Eigen
Classification: Unclassified
Component: Core - general (show other bugs)
Version: 3.2
Hardware: All All
: --- enhancement
Assignee: Hauke Heibel
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-12 21:15 UTC by Hauke Heibel
Modified: 2019-12-04 10:44 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.
Comment 7 Nobody 2019-12-04 10:44:05 UTC
-- 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.

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