C++11 – Why Pass by Value Recommended if Const Reference Costs Single Copy?

c++c++11move-semantics

I am trying to understand move semantics, rvalue references, std::move, etc. I have been trying to figure out, by searching through various questions on this site, why passing a const std::string &name + _name(name) is less recommended than a std::string name + _name(std::move(name)) if a copy is needed.

If I understand correctly, the following requires a single copy (through the constructor) plus a move (from the temporary to the member):

Dog::Dog(std::string name) : _name(std::move(name)) {}

The alternative (and old-fashioned) way is to pass it by reference and copy it (from the reference to the member):

Dog::Dog(const std::string &name) : _name(name) {}

If the first method requires a copy and move both, and the second method only requires a single copy, how can the first method be preferred and, in some cases, faster?

Best Answer

Consider calling the various options with an lvalue and with an rvalue:

```
Dog::Dog(const std::string &name) : _name(name) {}
```
Whether called with an lvalue or rvalue, this requires exactly one copy, to initialize _name from name. Moving is not an option because name is const.

Dog::Dog(std::string &&name) : _name(std::move(name)) {}

This can only be called with an rvalue, and it will move.

```
 Dog::Dog(std::string name) : _name(std::move(name)) {}
```
When called with an lvalue, this will copy to pass the argument and then a move to populate the data member. When called with an rvalue, this will move to pass the argument, and then move to populate the data member. In the case of the rvalue, moving to pass the argument may be elided. Thus, calling this with an lvalue results in one copy and one move, and calling this with an rvalue results in one to two moves.

The optimal solution is to define both (1) and (2). Solution (3) can have an extra move relative to the optimum. But writing one function is shorter and more maintainable than writing two virtually identical functions, and moves are assumed to be cheap.

When calling with a value implicitly convertible to string like const char*, the implicit conversion takes place which involves a length computation and a copy of the string data. Then we fall into the rvalue cases. In this case, using a string_view provides yet another option:

```
Dog::Dog(std::string_view name) : _name(name) {}
```
When called with a string lvalue or rvalue, this results in one copy. When called with a const char*, one length computation takes place and one copy.

Related Solutions

C++ – When to Prefer Pass-by-Value Over Pass-by-Const-Reference

Built-in types and small objects (such as STL iterators) should normally be passed by value.

This is partly to increase the compiler's opportunities for optimisation. It's surprisingly hard for the compiler to know if a reference parameter is aliasing another parameter or global - it may have to reread the state of the object from memory a number of times through the function, to be sure the value hasn't changed.

This is the reason for C99's restrict keyword (the same issue but with pointers).

C++ Pass by Const Reference vs Value – Why and How

There are two main considerations. One is the expense of copying the passed object and the second is the assumptions that the compiler can make when the object is a a local object.

E.g. In the first form, in the body of f it cannot be assumed that a and b don't reference the same object; so the value of a must be re-read after any write to b, just in case. In the second form, a cannot be changed via a write to b, as it is local to the function, so these re-reads are unnecessary.

void f(const Obj& a, Obj& b)
{
    // a and b could reference the same object
}

void f(Obj a, Obj& b)
{
    // a is local, b cannot be a reference to a
}

E.g.: In the first example, the compiler may be able to assume that the value of a local object doesn't change when an unrelated call is made. Without information about h, the compiler may not know whether an object that that function has a reference to (via a reference parameter) isn't changed by h. For example, that object might be part of a global state which is modified by h.

void g(const Obj& a)
{
    // ...
    h(); // the value of a might change
    // ...
}

void g(Obj a)
{
    // ...
    h(); // the value of a is unlikely to change
    // ...
}

Unfortunately, this example isn't cast iron. It is possible to write a class that, say, adds a pointer to itself to a global state object in its constructor, so that even a local object of class type might be altered by a global function call. Despite this, there are still potentially more opportunities for valid optimizations for local objects as they can't be aliased directly by references passed in, or other pre-existing objects.

Passing a parameter by const reference should be chosen where the semantics of references are actually required, or as a performance improvement only if the cost of potential aliasing would be outweighed by the expense of copying the parameter.

Best Answer

Related Solutions

C++ – When to Prefer Pass-by-Value Over Pass-by-Const-Reference

C++ Pass by Const Reference vs Value – Why and How

Related Question