Programming languages evolve according to the needs of those who use those languages. Mature languages such as C++ already provide all the tools necessary to write efficient machine code programs for a wide variety of platforms, but C++ is not a magic bullet to every type of problem. Then again it was never intended to be; it is a general purpose language. Specific problems demand specific solutions using specific languages. Nevertheless, C++ has more than surpassed its original design specification through a constantly-evolving standard, from C++98, C++11 and, most recently, C++14. Each new standard improves upon the previous standard by adding new language features and deprecating sub-optimal features. This means you can still use the older language features, so existing code will continue to work with the new standard, giving ample opportunity for developers to update existing code to the new standard should they choose to do so. However, this backward compatibility comes at a cost in that new language features may not be as elegant as they would be if the older feature could be dropped completely. For instance, new features can sometimes create inconsistencies in the language, but that;s a small price to pay for backward compatibility. Care must also be taken whenever introducing a new keyword or reserved word into the language, as those names may clash with user-defined names, which adds complexity to the language's compiler or interpreter.

To give a real-world example, prior to C++11 the only way to "move" an object (short of hand-crafting a user-defined solution) was to copy it. Every language provides some means of copying objects but it means that, for a brief moment at least, there are two instances of the same object in memory at the same time. If the object being copied is particularly large or particularly complex, this can have a huge impact upon performance. As a result, programmers were averse to passing objects to and from functions by value. This is particularly problematic when returning objects from functions because you cannot return a reference to a local object on the stack. when a function returns, that object falls from scope so it cannot be referenced. Instead, you must construct the object on the heap and return a pointer to it. In the absence of a user-defined memory manager, requesting memory from the heap has a runtime cost associated with it that you simply don't incur when allocating objects on the stack. After all, stack memory is pre-allocated so we only need to adjust the stack pointer to make that memory available which is done automatically whenever we instantiate a local variable. In addition, returning pointers to heap memory forces programmers to use pointer semantics rather than reference semantics and places the onus on the programmer to release heap memory when it is no longer required.

When we return a local object from a function we don't actually want a copy of that object because we know that the local object will fall from scope. What we really want to do is assign ownership of that object's resources to a new object, leaving the local object in an undefined but otherwise valid state such that it can be destroyed when it falls from scope. In other words, instead of copying the resources we want to move them. To use an analogy, when I borrow your car I don't expect you to go to the nearest keymaker to make me a copy of your key, I expect you to give me the key you already own. That is, I take ownership of the one and only key required to use your car.

In reality, we're actually swapping resources rather than moving resources. Although I have no resources to actually give you, that's what you end up with when you give me ownership of your key. The best way to look at move semantics is to look at the traditional swap semantic:

template<typename T>

void swap (T& x, T& y) {

T t = x;

x = y;

y = t;

}

At each stage of the swap, there are actually two instances of the same value in memory. That is, when we assign the value of x to t we end up with two copies of x. When we then assign y to x we have two copies of y. And when we assign t to y we have two copies of the original x. The t object falls from scope when the function returns, of course, but imagine if T were an array containing a million elements. That's a lot of copies and a lot of memory to consume when all we really wanted to do was swap the value of two objects.

Here's how we achieve that in C++11:

template<typename T> void swap (T& x, T& y) {

T t = std::move (x);

x = std::move (y);

y = std::move (t);

}

In order for this to work, type T must have both a move constructor and a move assignment member operator. If so, the std::move() function returns an rvalue reference to its argument. If not, the std::move() function just returns a standard rvalue. Thus objects that support move semantics will use that semantic, while those that do not will default to the standard copy semantic.

Unlike an rvalue, an rvalue reference is modifiable. So when we invoke a constructor or call an assignment operator with an rvalue reference, we use the object's move semantics rather than its copy semantics. Thus when we assign x to t, x takes on the value of t. What is the value of t? That is decided by the copy constructor itself. It may be a default value but any unspecified but otherwise valid value will do because t will fall from scope at the end of the function. In other words we don't actually care what value it initially holds, but that value will be assigned to x. Meanwhile, t will be be assigned the initial value of x. The actual implementation of the move is nothing more than a swap, not unlike the swap function itself.

When we come to assign y to x, remember that x now holds the original value of t which now moves to y. Meanwhile x takes on the original value of y. Finally, we assign t to y, and t currently holds the original value of x while y holds the original value of t. When we're done, t holds its original value, and x and y have swapped values. At every stage there was only ever one instance of the x and y values, and it really doesn't matter what value t had because it now falls from scope never to be seen again. This is as close to a "perfect" swap as you can get.

With move semantics in place, we can now pass and return objects by value:

template<typename T>

T f () {

return T{};

}

The above is the minimum return-by-value function we can define, which does nothing more than return a default constructed object of type T. Normally, this object would be returned by value but in C++11 it will be returned as an rvalue reference if type T supports move semantics. Note that we did not use the new keyword to allocate the object on the heap, it is a local object in every sense, but it now makes it possible to return objects by value efficiently, regardless of the complexity of type T:

int main () {

T t {f ()};

}

Of course the implementation of the move constructor or move assignment operator for a type T may in fact be less efficient than if we'd use pointer semantics. After all, copying a single pointer is as efficient as it gets. However, with well-defined classes where every class encapsulates one and only one resource, move semantics are not only just as efficient as pointer semantics, they actually become more efficient because you no longer have the overhead of using the heap. More importantly, move semantics leads to much cleaner code, with fewer low-level pointer semantics to distract the reader.

Of course, move semantics were always possible in C++, but they required that the programmer take full responsibility for the implementation. When working with code from several different programmers, there was no guarantee they all used the same design pattern, leading to inconsistencies and an even greater onus upon the programmer to accommodate them. Now that move semantics are a language feature in their own right, those inconsistencies are all but eliminated; older classes simply need to implement the move semantic in order to make use of them.

Resources

Top Categories

Product

Company