Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is this correct usage of C++ 'move' semantics?

Tonight I've been taking a look at some code I've been working on over the last few days, and began reading up on move semantics, specifically std::move. I have a few questions to ask you pros to ensure that I am going down the right path and not making any stupid assumptions!

Firstly:

1) Originally, my code had a function that returned a large vector:

template<class T> class MyObject { public:     std::vector<T> doSomething() const;     {         std::vector<T> theVector;          // produce/work with a vector right here          return(theVector);     }; // eo doSomething };  // eo class MyObject 

Given "theVector" is temporary in this and "throw-away", I modified the function to:

    std::vector<T>&& doSomething() const;     {         std::vector<T> theVector;          // produce/work with a vector right here          return(static_cast<std::vector<T>&&>(theVector));     }; // eo doSomething 

Is this correct? Any pitfalls in doing it this way?

2) I noticed in a function I have that returns std::string that it automatically called the move constructor. Debugging in to Return of the String (thankyou, Aragorn), I noticed it called an explicit move constructor. Why is there one for the string class and not vector?

I didn't have to make any modifications to this function to take advantage of move semantics:

// below, no need for std::string&& return value? std::string AnyConverter::toString(const boost::any& _val) const {     string ret;     // convert here     return(ret); // No need for static_cast<std::string&&> ? }; // eo toString 

3) Finally, I wanted to do some performance tests, is the amazingly-fast results I got because of std::move semantics or did my compiler (VS2010) do some optimizing too?

(Implementation of _getMilliseconds() omitted for brevity)

std::vector<int> v; for(int a(0); a < 1000000; ++a)     v.push_back(a);  std::vector<int> x; for(int a(0); a < 1000000; ++a)     x.push_back(a);      int s1 = _getMilliseconds(); std::vector<int> v2 = v;     int s2 =  _getMilliseconds(); std::vector<int> v3 = std::move(x);     int s3 =  _getMilliseconds();      int result1 = s2 - s1;     int result2 = s3 - s2; 

The results were, obviously, awesome. result1, a standard assignment, took 630ms. The second result, was 0ms. Is this a good performance test of these things?

I know some of this is obvious to a lot of you, but I want to make sure I understand the semantics right before I go blazer on my code.

Thanks in advance!

like image 389
Moo-Juice Avatar asked Nov 10 '10 19:11

Moo-Juice


People also ask

Does C have move semantics?

C doesn't have a direct equivalent to move semantics, but the problems that move semantics solve in c++ are much less common in c: As c also doesn't have copy constructors / assignment operators, copies are by default shallow, whereas in c++ common practice is to implement them as deep copy operations or prevent them ...

When should I use move semantics?

Move semantics allows you to avoid unnecessary copies when working with temporary objects that are about to evaporate, and whose resources can safely be taken from that temporary object and used by another.

What is a move semantic?

Move semantics is a set of semantic rules and tools of the C++ language. It was designed to move objects, whose lifetime expires, instead of copying them. The data is transferred from one object to another. In most cases, the data transfer does not move this data physically in memory.

Are move semantics important?

Move semantics allows an object, under certain conditions, to take ownership of some other object's external resources. This is important in two ways: Turning expensive copies into cheap moves. See my first answer for an example.


1 Answers

A reference is still a reference. In the same way you cannot return a reference to a local in C++03 (or you get UB), you can't in C++0x. You'll end up with a reference to a dead object; it just happens to be an rvalue reference. So this is wrong:

std::vector<T>&& doSomething() const {     std::vector<T> local;      return local; // oops     return std::move(local); // also oops } 

You should just do what you saw in number two:

// okay, return by-value  std::vector<T> doSomething() const {     std::vector<T> local;      return local; // exactly the same as:     return std::move(local); // move-construct value } 

Variables local to a function are temporary when you return, so there's no need to change any of your code. The return type is the thing responsible for implementing move semantics, not you.

You want to use std::move to explicitly move something, when it wouldn't be done normally, like in your test. (Which seems to be fine; was that in Release? You should output the contents of the vector, or the compiler will optimize it away.)

If you want to learn about rvalue references, read this.

like image 157
GManNickG Avatar answered Sep 20 '22 09:09

GManNickG