Ultimate copy elision

“...take no action on CWG #6 issue until an interested party
produces a paper with analysis and a proposal.”

― CWG #6

III. History of the problem

First copy elision rules were proposed in 1995 in N0641 "Copy optimization". Those rules were quite close to what was proposed in the early versions of this paper. Here they are:

Whenever a class object is copied and the implementation can prove that either the original or the copy will never again be used, an implementation is permitted to treat the original and the copy as two different ways of referring to the same object and not generate a copy at all. In that case, the object is destroyed at the later of the times when the original and the copy would have been destroyed without the optimization.

N0641 "Copy optimization" was adopted into the C++ WD in N0661 "WG21 Meeting No. 12". Two years later issues were found and described in N1079 "Core WG List of new issues":

  Thing x = /* some value */;
  SubThing y = x.extract_portion();
  Thing z = x;
  z.clobber_portion();
  // now try to fetch the value of y

That issue was discussed multiple times, including N1108 "WG21 Meeting No. 19". In that paper two cases where Core especially wanted to allow copy elisions were highlighted:

• elision of copy of temporary values,
• elision of copy of return value.

Core would conduct further work to look at other optimizations.

Finally, in N1182 "Proposed Resolutions for Core Language Issues 6, 14, 20, 40, and 89" appeared the copy elision rules close to the ones we have now. Since then we have an open issue CWG #6 as a reminder that C++ could do better than now.

Part I

As was noted in N1079 object could "bind" its resources to other objects:

char* some;

struct binds_resource {
    binds_resource() = default;
    binds_resource(const binds_resource& other) = default;

    void bind() {
        some = data.data();
    }

    string data = "A";
};


void test() {
    binds_resource original{};
    original.bind();

    shared_state copy{original};
    copy.data = "B";
    assert(some != copy.data);
}

If in the above example we enable to elide copy and use original instead, then the assertion will fail.

Let's concentrate on a simpler case, when the original object is not accessed between construction and copying and when the original object is not accessed after copying and destruction. For such a simple case we still may get into trouble, if the original object "binds" its resources in constructor:

char* some;

struct binds_resource {
    binds_resource()
        : data{"A"}
    {
        bind();
    }

    binds_resource(const binds_resource& other) = default;

    void bind() {
        some = data.data();
    }

    string data = "A";
};


void test() {
    binds_resource original{};
    shared_state copy{original};
    copy.data = "B";
    assert(some != copy.data);
}

Such binding could also happen via constructor output parameters:

struct binds_resource {
    binds_resource(char** out)
        : data{"A"}
    {
        *out = data.data();
    }

    binds_resource(const binds_resource& other) = default;
    string data = "A";
};


void test() {
    char* some;
    binds_resource original{&some};

    shared_state copy{original};
    copy.data = "B";
    assert(some != copy.data);
}

More problems. We may get into troubles with eliding copies of resources that are used by different threads:

mutex m;

void takes_by_copy(std::string v) noexcept {
    m.unlock();
    v += "Oops."; // must work with copy!
}

void test() {
    m.lock();

    std::string original{"some string that is too big for SSO"};

    std::thread t{
        [&original]() {
            m.lock();
            // under the lock
            // ...
        }
    };

    takes_by_copy(original);

    t.join();
}

Note that the scope of the Source should remain the same or extend after the elision:

struct locked_mutex {
    mutex m{};
    lock_guard<mutex> lock{m};
};

void test() {
    shared_ptr<locked_mutex> original = std::make_shared<mutex>();

    // acessing resource that should be protected by lock

    shared_state copy{original};
}

Finally, we may get into troubles with eliding copies between different threads of execution:

void test() {
    some_shared_spin_guard original{spinlock};

    std::thread{
        [](const auto& lock) { /* under the lock */ },
        original
    }.detach();

    // original should be destroyed here and should release the lock here!
}

Conclusion: carefully investigating all the above cases we could enable the copy elisions for the case when:

• Source is not accessed between construction and copy
• and Source is not accessed between copy and destruction
• and Source and Target belong to the same thread of execution
• and Source and Target have automatic storage duration
• and Source construction does not access any global variables and does not return values through output parameters
• and scope of Source after the elision extends to the scope of the target

Benefits: With above rules we get copy elisions in the following popular cases:

Case 1. CWG #6

void takes_by_copy(std::string v) noexcept { /* ... */ }

void example() {
    string v{"some string that is too big for SSO"};
    takes_by_copy(v);
}

Case 2. CWG #6

void takes_by_creference(const std::string& v) noexcept {
    std::string copy{v};
    /* ... */
}

void example() {
    return takes_by_creference("some string that is too big for SSO");
}

As Jens Maurer noted a sligtly modified example leads to UB: 'Given your copy elision rules, it seems "copy" could alias "s", introducing undefined behavior (see 9.1.7.1 [dcl.type.cv] p4).'

void takes_by_creference(const std::string& v) noexcept {
    std::string copy{v};
    copy += "blah";
}

void example() {
    const std::string s("some string);
    return takes_by_creference(s);
}

This paper proposes to adjust [dcl.type.cv] p4 making that behavior well defined.

Case 3. CWG #1049

struct B {
   string a;
   B(const string& a): a(a) { }
};

int main() {
   B("some string that is too big for SSO");
}

Part II: Source leaves scope

Now let's concentrate on another case: when the source object is destroyed right after the copy/move construction:

char* some;

struct binds_resource {
    binds_resource()
        : data{"A"}
    {
        bind();
    }

    binds_resource(const binds_resource& other) = default;

    void bind() {
        some = data.data();
    }

    string data = "A";
};

void test() {
    auto generate = []() {
        binds_resource source{};
        return source; // NRVO is possible
    };

    auto copy = generate();

    copy.data = "B";
    assert(some != copy.data); // UB
}

Existing rules already rely on the fact that the object that leaves scope should not be referenced outside the scope. Let's change example to have no UB:

shared_ptr<int> some;

struct shares_state {
    shares_state()
        : data{make_shared<int>(42)}
    {
        bind();
    }

    shares_state(const shares_state& other) {
        data = make_shared<int>(*other.data);
    }

    void bind() {
        some = data;
    }

    shared_ptr data;
};

void test() {
    auto generate = []() {
        shares_state source{};
        return source; // NRVO is possible
    };

    auto copy = generate();

    *copy.data = 0;
    assert(*some != *copy.data); // Implementation defined
}

In other words: we don't have to check for "binding" if the scope of Source ends right after the copy/move construction.

Conclusion: we can relax the rule in "Part I" for the cases when the scope of Source ends immediately after the copy/move construction:

• Source is not accessed between copy and destruction
• and Source and Target have automatic storage duration
• and Source and Target belong to the same thread of execution
• and scope of Source after the elision extends to the scope of the target
• and either
  • scope of Source ends after the copy/move construction of Target
  • or Source is not accessed between construction and copy, and Source construction does not access any global variables and does not return values through output parameters

Benefits: With above rules we get copy elisions in the following popular cases:

Case 1. Returning a function parameter

string callee(string v) {
    // any code
    return v;  // copy could be elided
}

auto example() {
    auto v = callee("some string that is too big for SSO");
    return v.size();
}

Case 2. Returning a reference to a local

string callee() {
    string v{"some string that is too big for SSO"};
    const auto& ref = v;
    return ref;  // copy could be elided
}

auto example() {
    auto v = callee();
    return v.size();
}

Case 3. Move by mistake

string callee() {
    string v{"some string that is too big for SSO"};
    return std::move(v);  // copy could be elided
}

auto example() {
    auto v = callee();
    return v.size();
}

Part III: Simple destructors and constructors

It may be hard to implement the above copy elision logic without taking additional care of compiler specifics. Some compilers at certain stages of optimization may inline constructors/destructors and just call the constructors/destructors of the members. So in the assembly (and probably in the IR) code like:

void test1() {
    std::pair<A, A> pair;
    (void)pair;
}

test1():
  push rbp
  sub rsp, 16
  mov rdi, rsp
  call A::A()
  lea rdi, [rsp+8]
  call A::A()
  lea rdi, [rsp+8]
  call A::~A()
  mov rdi, rsp
  call A::~A()
  add rsp, 16
  pop rbp
  ret

With such representations it could be hard to distinguish `pair` objects from `A` objects. To minimize the changes required to implement the elision rules this paper proposes to allow eliding subobjects, while the elision rules from "Part I" and "Part II" are not violated.

Note that the proposed changes may change the destruction order of nested objects:

string callee() {
    pair<string, string> v = foo();
    return v.second;
}

auto test() {
    auto v = callee();
    return v.size();
}


auto pseudocode_with_proposed_changes() {
    pair<string, string> v = foo();
    v.first.~string();
    return v.size();
    // do not call destructor of `v`, just destroy `v.second`
}

Let's invent an example where such optimization could break some code:

struct local_vector {
    pmr::monotonic_buffer_resource mr;
    pmr::vector<int> data{&mr};
};

auto callee() {
    local_vector lv;
    lv.data.resize(1000, 42);

    return lv.data; // copying
}

auto test() {
    auto v = callee(); // `mr` is destroyed, but during copying default memory resource is used
    /*...*/
}

With the proposed copy elision rules the above example becomes broken: there'll be no copying so the old memory resource will be used, that is destroyed.

Note that the example is already shaky. Minor changes result in broken code:

auto callee0() {
    monotonic_buffer_resource mr;
    pmr::vector<int> v(&mr);
    v.resize(1000, 42);
    return v;
}

auto test0() {
    auto v = callee(); // Already broken
}

In this paper we'd like to suggest enabling copy elision for the above rules and make an emergency hatch for disabling copy/move elisions for cases like above.

Conclusion: relax the rule in "Part II" by allowing copy elision for subobjects and make an "emergency hatch" for cases when copies are required. See "VII. Proposed wording" for the wording.

Benefits: With above rules we get copy elisions in the following popular cases:

Case 1. Returning a subobject

static string callee() {
    pair<string, string> v;
    return v.second;
}

Case 2. Returning an element from a structured binding

static string callee() {
    auto [f, s] = pair{};
    return s;
}

Case 3. CWG #1579

  optional<T> foo() {
    T t;
    ...
    // inlining the constructor of `optional` may result in internal storage of optional being
    // initialized by constructing T from `t`, which scope ends.
    return t; 
  }

V. Implementability example.

Let's take a look at some pseodocode representing the C++ program after the inlining optimization:

struct A {
    A() __attribute__ ((pure)); // "pure" is detected by the compiler
    A(const A&);
    A(A&&) = default __attribute__ ((pure)); // "pure" is detected by the compiler
    ~A();

    int some_function();
private:
    // members
};

int caller() {
    A a;
    a.some_function();
    A b{a};             // scope of `a` ends immediately after the copy constructor call, eliding `b` and using `a` with extended scope
    [[end of scope `a`]]

    A c{b}; // `a` is accessed between this line, no copy elision allowed
    A d{c}; // `c` is not accessed after copy construction and its copy constructor is a "pure" function. OK to elide
    return d.some_function()
}