Page History

...

When implementing a copy operator, do not mutate any externally observable members of the source object operand or globally accessible information. Externally observable members include, but are not limited to, members that participate in comparison or equality operations, members whose values are exposed via public APIs, and global variables.

Before C++11, a copy operation that mutated the source operand was the only way to provide move-like semantics. However, the language did not provide a way to enforce that this operation only occurred when the source operand was at the end of its lifetime, which led to fragile APIs like std::auto_ptr. In C++11 and later, such a situation is a good candidate for a move operation instead of a copy operation.

auto_ptr

For example, in C++03, std::auto_ptr had the following copy operation signatures (note: std::auto_ptr was deprecated in C++11) [ISO/IEC 14882-2003]:

Both copy construction and copy assignment would mutate the source argument, A, by effectively calling this->reset(A.release()). However, this invalidated assumptions made by standard library algorithms such as std::sort(), which may need to make a copy of an object for later comparisons [Hinnant 05]. Consider an implementation the following implementation of std::sort() that implements the quick sort algorithm:.

// ...
value_type pivot_element = *mid_point;
// ...

At this point, the sorting algorithm assumes that pivot_element and *mid_point have equivalent value representations and will compare equal. However, for std::auto_ptr, this is not the case because *mid_point has been mutated, and mutated and results in unexpected behavior.

Generally, a copy operation that mutates the source operand is a safe operation to perform only when the source operand is at the end of its lifetime, because the value representation of the source operand is not important. Such a situation is a good candidate for a move operation instead of a copy operationIn C++11, the std::unique_ptr smart pointer class was introduced as a replacement for std::auto_ptr to better specify the ownership semantics of pointer objects. Rather than mutate the source argument in a copy operation, std::unique_ptr explicitly deletes the copy constructor and copy assignment operator, and instead uses a move constructor and move assignment operator. Subsequently, std::auto_ptr was deprecated in C++11.

Noncompliant Code Example

In this noncompliant code example, the copy operations for A mutate the source operand by resetting its member variable m to 0. When std::fill() is called, the first element copied will have the original value of obj.m, 12, at which point obj.m is set to 0. The subsequent nine copies will all retain the value 0.

#include <algorithm>
#include <vector>

class A {
  mutable int m;
  
public:
  A() : m(0) {}
  explicit A(int m) : m(m) {}
  
  A(const A &other) : m(other.m) {
    other.m = 0;
  }
  
  A& operator=(const A &other) {
    if (&other != this) {
      m = other.m;
      other.m = 0;
    }
    return *this;
  }
  
  int get_m() const { return m; }
};

void f() {
  std::vector<A> v{10};
  A obj(12);
  std::fill(v.begin(), v.end(), obj);
}

Compliant Solution

In this compliant solution, the copy operations for A no longer mutate the source operand, ensuring that the vector contains equivalent copies of obj. Instead, A has been given move operations that perform the mutation when it is safe to do so.

#include <algorithm>
#include <vector>

class A {
  int m;
  
public:
  A() : m(0) {}
  explicit A(int m) : m(m) {}
  
  A(const A &other) : m(other.m) {}
  A(A &&other) : m(other.m) { other.m = 0; }
  
  A& operator=(const A &other) {
    if (&other != this) {
      m = other.m;
    }
    return *this;
  }
 
  A& operator=(A &&other) {
    m = other.m;
    other.m = 0;
    return *this;
  }
  
  int get_m() const { return m; }
};

void f() {
  std::vector<A> v{10};
  A obj(12);
  std::fill(v.begin(), v.end(), obj);
}

Exceptions

OOP58-CPP-EX0: Reference counting, and implementations such as std::shared_ptr<> constitute an exception to this rule. Any copy or assignment operation of a reference-counted object requires the reference count to be incremented. The semantics of reference counting are well-understood, and it can be argued that the reference count is not a salient part of the shared_pointer object.

Risk Assessment

Copy operations that mutate the source operand or global state can lead to unexpected program behavior. In the case of using Using such a type in a Standard Template Library container or algorithm , this can also lead to undefined behavior.

Automated Detection

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

Bibliography

...

...

Image Modified Image Modified Image Modified