C++ Core Guidelines: Rules about Don'ts

This post is about don'ts. Here are the two most important rules of this post: Don't use std::move thoughtless and don't slice. Let's start.

Here are the don'ts for today.

• ES.56: Write std::move() only when you need to explicitly move an object to another scope
• ES.60: Avoid new and delete outside resource management functions
• ES.61: Delete arrays using delete[] and non-arrays using delete
• ES.63: Don’t slice

The first rule is a disguised don't. 

ES.56: Write std::move() only when you need to explicitly move an object to another scope

Most of the time, there is no need to explicitly call std::move.The compiler automatically applies move semantic if the source of the operation is a rvalue. A rvalue is an object with no identity. A rvalue has typically no name, and you can not get its address. The remaining objects are lvalues. 

Applying std::move to a lvalue gives most of the time an empty object. The lvalue is afterwards in a so-called moved-from state. This means that it is in a valid but no nearer specified state. Sound strange? Right! You have just keep this rule in mind: After you move from a lvalue such as std::move(source) you can not make any assumption about source. You have to set it to a new value.

Wait a second. The rule says you should only use std::move if you want to move an object to another scope. The classical use-cases are objects which can not be copied but moved. For example, you want to move a std::promise into another thread. 

// moveExplicit.cpp

#include <future>
#include <iostream>
#include <thread>
#include <utility>

void product(std::promise<int>&& intPromise, int a, int b){     // (1)
  intPromise.set_value(a * b);
}

int main(){

  int a= 20;
  int b= 10;

  // define the promises
  std::promise<int> prodPromise;

  // get the futures
  std::future<int> prodResult= prodPromise.get_future();

  // calculate the result in a separat thread
  std::thread prodThread(product,std::move(prodPromise), a, b);   // (2)
 
  // get the result
  std::cout << "20 * 10 = " << prodResult.get() << std::endl;     // 200
  
  prodThread.join();

}

The function product (1) gets the std::promise by rvalue reference. A promise cannot be copied but moved; therefore, std::move is necessary (2) to move the promise into the newly created thread. 

Here is the big don't! Don't use std::move in a return statement. 

vector<int> make_vector() {
    vector<int> result;
    // ... load result with data
    return std::move(result);       // bad; just write "return result;"
}

Trust your optimizer! If you return the object just by copy, the optimizer will do its job. This is best practices until C++14; this is an obligatory rule since C++17 and is called guaranteed copy elision. Although this technique is called automatic copy elision, move operations are also optimized away with C++11.

RVO stands for Return Value Optimization and means, that the compiler is allowed to remove unnecessary copy operations. What was until C++14 a possible optimization step becomes in C++17 a guarantee.

MyType func(){
  return MyType{};         // (1) no copy with C++17
}
MyType myType = func();    // (2) no copy with C++17

Two unnecessary copy operations can happen in these few lines. The first one in (1) and the second one in (2). With C++17, both copy operations are not allowed.

If the return value has a name, it's called NRVO. This acronym stands for Named Return Value Optimization.

MyType func(){
  MyType myVal;
  return myVal;            // (1) one copy allowed 
}
MyType myType = func();    // (2) no copy with C++17

The subtle difference is that the compiler can still copy the value myValue according to C++17 (1). But no copy will take place in (2). 

ES.60: Avoid new and delete outside resource management functions

 Okay, I can make it short. Don't use new and delete the application code. This rule has a nice reminder: "No naked new!". 

ES.61: Delete arrays using delete[] and non-arrays using delete

Here is the rationale for the last rule. Resource management in application code is error-prone.

void f(int n)
{
    auto p = new X[n];   // n default constructed Xs
    // ...
    delete p;   // error: just delete the object p, rather than delete the array p[]
}

The guidelines state in the comment: "just delete the object p". Let me put it more drastically. This is undefined behavior!

ES.63: Don’t slice

First of all. What is slicing? Slicing means: you want to copy an object during assignment or initialization, and you get only a part of the object. 

Let's start simple.

// slice.cpp

struct Base { 
  int base{1998};
}
 
struct Derived : Base { 
  int derived{2011};
}

void needB(Base b){
    // ...
}
 
int main(){

  Derived d;
  Base b = d;              // (1)
  Base b2(d);              // (2)
  needB(d);                // (3)

}

The lines (1), (2), and (3) have all the same effect: the Derived part of d is removed. I assume that was not your intention.

I said in the announcement to this post that slicing is one of the darkest parts of C++. Now it becomes dark.

// sliceVirtuality.cpp

#include <iostream>
#include <string>

struct Base { 
    virtual std::string getName() const {        // (1)
        return "Base";       
    }
};
 
struct Derived : Base { 
    std::string getName() const override {       // (2)
        return "Derived";
    }
};
 
int main(){
    
    std::cout << std::endl;
    
    Base b;
    std::cout << "b.getName(): " << b.getName() << std::endl;       // (3)
    
    Derived d;
    std::cout << "d.getName(): " << d.getName() << std::endl;       // (4)
    
    Base b1 = d;
    std::cout << "b1.getName():  " << b1.getName() << std::endl;    // (5)
   
    Base& b2 = d;
    std::cout << "b2.getName():  " << b2.getName() << std::endl;    // (6)

    Base* b3 = new Derived;
    std::cout << "b3->getName(): " << b3->getName() << std::endl;   // (7)
    
    std::cout << std::endl;

}

I created a small hierarchy consisting of the Base and the Derived class. Each object of this class hierarchy should return its name. I made the method getName virtual (1) and overrode it in (2); therefore, I will have polymorphism. This means I can use a derived object via a reference (6) or a pointer to a base object (7). Under the hood, the object is of type Derived. 

This will not hold, if I just copy Derived d to Base b1 (5). In this case, slicing kicks in, and I have a Base object under the hood. In the case of copying, the declared or static type is used. If you use an indirection such as a reference or a pointer, the actual or dynamic type is used. 

To keep the rule in mind is quite simple: If your instances of a class should be polymorphic, it should declare or inherit at least one virtual method, and you should use its objects via an indirection such as a pointer or a reference. 

Of course, there is a cure for slicing: provide a virtual clone function. Read the details here: C++ Core Guidelines: Rules for Copy and Move.

What's next

This post was about don'ts. The next post will start with a do. Use curly braces for initialization of data.