Question: I would like to make sure destructor side effects are retained in a function which is a candidate for RVO. My goal is to snapshot the stack at entry and exit and have the expected stack variables present. This code seems to work for C++11 without using compiler specific options but I don't know a way to do this in earlier versions without adding spurious instances of Test to create multiple return paths. Is there some technique and does this always work for c++11?

```
class Test {
public:
    int m_i;
    Test() { m_i = 0; cout << "def_ctor" << endl; }
    Test(const Test& arg) { this->m_i = arg.m_i; cout << "copy_ctor" << endl;}
    ~Test() { cout << "dtor needed for side effects" << endl; }
};

Test foo() {
    Test ret;
    return std::move(ret);
}

int main()
{
    Test x=foo();
}

```

Answer: 
`std::move` isn't magic, it's just a function that returns a reference to its argument, so you should be able to do the same in any version of C++

```
template<typename T>
  const T&
  defeat_rvo(const T& t)
  { return t; }

Test foo() {
    Test ret;
    return defeat_rvo(ret);
}

```

I think you can also do it more directly, by just returning a reference:

```
Test foo() {
    Test ret;
    const Test& ref = ret;
    return ref;
}

```

The copy elision rules say that the local object can be constructed directly in the return value when the expression in the return statement is "the name of a non-volatile automatic object", which is not the case here, as it's a reference to the object, not the name of the object itself. I'm less certain about that case, but a cast should work:

```
Test foo() {
    Test ret;
    return static_cast<const Test&>(ret);
}

```

This definitely isn't the name of the object, or the name of an alias to the object, it's a cast expression.
Don't return an object you do not want to be elided; any such change is going to be fragile under future maintenance or refactoring.

In general, an object should support elision in the cases where it can occur; this places semantic restrictions on what a move or copy construction can be, and what a destructor does.

Violating these semantic restrictions is easy (`template<class T> T copy_of(T const& t){return t;}`, then `return copy_of(whatever);`, or a `static_cast`, or whatever). It being easy does not mean it is safe, from a code maintainability perspective.