CODEWITHSUNDEEP
c++c++11move-semantics
TNA
TNA

Reputation: 2745

Why not auto move if object is destroyed in next step?

If a function return a value like this:

std::string foo() {
  std::string ret {"Test"};
  return ret;
}

The compiler is allowed to move ret, since it is not used anymore. This doesn't hold for cases like this:

void foo (std::string str) {
  // do sth. with str
}

int main() {
  std::string a {"Test"};
  foo(a);
}

Although a is obviously not needed anymore since it is destroyed in the next step you have to do:

int main() {
  std::string a {"Test"};
  foo(std::move(a));
}

Why? In my opinion, this is unnecessarily complicated, since rvalues and move semantic are hard to understand especially for beginners. So it would be great if you wouldn't have to care in standard cases but benefit from move semantic anyway (like with return values and temporaries). It is also annoying to have to look at the class definition to discover if a class is move-enabled and benefits from std::move at all (or use std::move anyway in the hope that it will sometimes be helpfull. It is also error-prone if you work on existing code:

int main() {
  std::string a {"Test"};
  foo(std::move(a));

  // [...] 100 lines of code
  // new line:
  foo(a); // Ups!
}

The compiler knows better if an object is no longer used used. std::move everywhere is also verbose and reduces readability.

Upvotes: 3

Views: 300

Answers (4)

flimberger
flimberger

Reputation: 171

While the compiler is allowed to move ret in your first snippet, it might also do a copy/move elision and construct it directly into the stack of the caller. This is why it is not recommended to write the function like this:

std::string foo() {
    auto ret = std::string("Test");

    return std::move(ret);
}

Now for the second snippet, your string a is a lvalue. Move semantics only apply to rvalue-references, which obtained by returning a temporary, unnamed object, or casting a lvalue. The latter is exactly what std::move does.

std::string GetString();

auto s = GetString();

// s is a lvalue, use std::move to cast it to rvalue-ref to force move semantics
foo(s);

// GetString returns a temporary object, which is a rvalue-ref and move semantics apply automatically
foo(GetString());

Upvotes: 0

David Haim
David Haim

Reputation: 26496

Its all sums up on what you define by "Destroyed"? std::string has no special effect for self-destroying but deallocating the char array which hides inside.

what if my destructor DOES something special? for example - doing some important logging? then by simply "moving it because it's not needed anymore" I miss some special behavior that the destructor might do.

Upvotes: 1

Giulio Franco
Giulio Franco

Reputation: 3230

It is not obvious that an object is not going to be used after a given point. For instance, have a look at the following variant of your code:

struct Bar {
  ~Bar() { std::cout << str.size() << std::endl; }
  std::string& str;
}

Bar make_bar(std::string& str) {
  return Bar{ str };
}

void foo (std::string str) {
  // do sth. with str
}

int main() {
  std::string a {"Test"};
  Bar b = make_bar(a);
  foo(std::move(a));
}

This code would break, because the string a is put in an invalid state by the move operation, but Bar is holding a reference to it, and will try to use it when it's destroyed, which happens after the foo call.

If make_bar is defined in an external assembly (e.g. a DLL/so), the compiler has no way, when compiling Bar b = make_bar(a);, of telling if b is holding a reference to a or not. So, even if foo(a) is the last usage of a, that doesn't mean it's safe to use move semantics, because some other object might be holding a reference to a as a consequence of previous instructions.

Only you can know if you can use move semantics or not, by looking at the specifications of the functions you call.

On the other side, you can always use move semantics in the return case, because that object will go out of scope anyway, which means any object holding a reference to it will result in undefined behaviour regardless of the move semantics. By the way, you don't even need move semantics there, because of copy elision.

Upvotes: 7

StenSoft
StenSoft

Reputation: 9609

Because compilers cannot do optimizations that change behavior of the program except when allowed by the standard. return optimization is allowed in certain cases but this optimization is not allowed for method calls. By changing the behavior, it would skip calling copy constructor and destructor which can have side effects (they are not required to be pure) but by skipping them, these side effects won't happen and therefore the behavior would be changed.

(Note that this highly depends on what you try to pass and, in this case, STL implementation. In cases where all code is available at the time of compilation, the compiler may determine both copy constructor and destructor are pure and optimize them out.)

Upvotes: 0

Related Questions