Page History

An object deriving from a base class typically contains additional member variables that extend the base class. When by-value assigning or copying an object of the derived type to an object of the base type, those additional member variables are not copied because the base class contains insufficient space in which to store them. This action is commonly called slicing the object because the additional members are "sliced off" the resulting object.

Do not initialize an object of base class type with an object of derived class type, except through references, pointers, or pointer-like abstractions (such as std::unique_ptr, or std::shared_ptr).

Noncompliant Code Example

In this noncompliant code example, an object of the derived Manager type is passed by value to a function accepting a base Employee type. Consequently, the Manager objects are sliced, resulting in information loss and unexpected behavior when the print() function is called

Copying a polymorphic object by value can easily result in the object being sliced. That is, only part of the information associated with the object is copied, and the remaining information is lost.

Non-Compliant Code Example

This code example is non-compliant because of the unintended data loss.

#include <iostream>
#include <string>

class Employee {
public:
  Employee(string theName) : name(theName) {}std::string name;
  string getName() const {return name;}
protected:
  virtual void print(std::ostream &os) const {
    coutos << "Employee: " << getNameget_name() << std::endl;      
  }
  
privatepublic:
  Employee(const std::string name;
};

class Manager : public Employee {
public:
  Manager(string theName, Employee theEmployee) :&name) : name(name) {}
  const std::string &get_name() const { return name; }
  friend std::ostream &operator<<(std::ostream &os, const Employee &e) {
    Employeee.print(theName), assistant(theEmployee) {os);
    return os;
  }
};
 
class Manager : public Employee getAssistant(){
 const {returnEmployee assistant;}
  
protected:
 virtual void print(std::ostream &os) const override {
    coutos << "Manager: " << getNameget_name() << std::endl;
    coutos << "Assistant: " << assistant.getNamestd::endl << "\t" << get_assistant() << std::endl;      
  }
private:
  Employee assistant;
  
public:
  Manager(const std::string &name, const Employee &assistant) : Employee(name), assistant(assistant) {}
  const Employee &get_assistant() const { return assistant; }
};

void f(Employee e) {
  std::cout << e;    
}

int main () {
  Employee coder("Joe Smith");
  Employee typist("Bill Jones");
  Manager designer("Jane Doe", typist);
  
  f(coder);
 = designer;  // slices Jane Doe!f(typist);
  coder.printf(designer);
}

In this code, class Manager is derived from class Employee and adds additional information, namely the data member assistant. In main, the object designer of class Manager, which contains an assistant data member typist, is copied by value to the object coder of class Employee. This results in the designer object being sliced, and only the Employee information is copied. Hence, the print() statement results in the output:

Employee: Jane Doe

The information about Jane Doe's assistant is lost.

Compliant Solution

When f() is called with the designer argument, the formal parameter in f() is sliced and information is lost. When the object e is printed, Employee::print() is called instead of Manager::print(), resulting in the following output:

Employee: Jane Doe

Compliant Solution (Pointers)

Using the same class definitions as the noncompliant code example, this compliant solution modifies the definition of f() to require raw pointers to the object, removing the slicing problemAssuming exactly the same class structure as above, if pointers to the objects are used so that objects are copied by reference, then slicing does not occur.

int main (// Remainder of code unchanged...
 
void f(const Employee *e) {
  if (e) {
  Employee *coder = new Employee  std::cout << *e;
  }
}

int main() {
  Employee coder("Joe Smith");
  Employee *typist = new Employee("Bill Jones");
  Manager *designer = new Manager("Jane Doe", *typist);
  
  f(&coder);
 = designerf(&typist);
  coder->printf(&designer);
}

Now, the object designer is not sliced, and the output is:

Manager: Jane Doe
Assistant: Bill Jones

...

This compliant solution also complies with EXP34-C. Do not dereference null pointers in the implementation of f(). With this definition, the program correctly outputs the following.

Employee: Joe Smith
Employee: Bill Jones
Manager: Jane Doe
Assistant: 
	Employee: Bill Jones

Compliant Solution (References)

An improved compliant solution, which does not require guarding against null pointers within f(), uses references instead of pointers.

// ... Remainder of code unchanged ...
 
void f(const Employee &e) {
  std::cout << e;
}

int main() {
  Employee coder("Joe Smith");
  Employee typist("Bill Jones");
  Manager designer("Jane Doe", typist);
  
  f(coder);
  f(typist);
  f(designer);
}

Compliant Solution (Noncopyable)

Both previous compliant solutions depend on consumers of the Employee and Manager types to be declared in a compliant manner with the expected usage of the class hierarchy. This compliant solution ensures that consumers are unable to accidentally slice objects by removing the ability to copy-initialize an object that derives from Noncopyable. If copy-initialization is attempted, as in the original definition of f(), the program is ill-formed and a diagnostic will be emitted. However, such a solution also restricts the Manager object from attempting to copy-initialize its Employee object, which subtly changes the semantics of the class hierarchy.

int main () {
  auto_ptr<Employee> coder( new Employee("Joe Smith") );
  auto_ptr<Employee> typist( new Employee("Bill Jones") );
  auto_ptr<Manager> designer( new Manager("Jane Doe", *typist) );

  coder = designer; // Smith deleted, Doe xferred
  coder->print();
  // everyone deleted
}

Alternatively, references may be used to refer to the various derived employee objects.

int main #include <iostream>
#include <string>

class Noncopyable {
  Noncopyable(const Noncopyable &) = delete;
  void operator=(const Noncopyable &) = delete;
  
protected:
  Noncopyable() = default;
};

class Employee : Noncopyable {
  // Remainder of the definition is unchanged.
  std::string name;
  
protected:
  virtual void print(std::ostream &os) const {
    os << "Employee: " << get_name() << std::endl;      
  }
  
public:
  Employee(const std::string &name) : name(name) {}
  const std::string &get_name() const { return name; }
  friend std::ostream &operator<<(std::ostream &os, const Employee &e) {
    e.print(os);
    return os;
  }
};
 
class Manager : public Employee {
  const Employee &assistant; // Note: The definition of Employee has been modified.

  // Remainder of the definition is unchanged.
protected:
  void print(std::ostream &os) const override {
    os << "Manager: " << get_name() << std::endl;
    os << "Assistant: " << std::endl << "\t" << get_assistant() << std::endl;      
  }
  
public:
  Manager(const std::string &name, const Employee &assistant) : Employee(name), assistant(assistant) {}
  const Employee &get_assistant() const { return assistant; }
};
 
// If f() were declared as accepting an Employee, the program would be
// ill-formed because Employee cannot be copy-initialized.
void f(const Employee &e) {
  std::cout << e;
}

int main() {
  Employee coder("Joe Smith");
  Employee typist("Bill Jones");
  Manager designer("Jane Doe", typist);

  Employee
 &toPrint = designer;  // Jane remains entire
  toPrint.print( f(coder);
  f(typist);
  f(designer);
}

Noncompliant Code Example

This noncompliant code example uses the same class definitions of Employee and Manager as in the previous noncompliant code example and attempts to store Employee objects in a std::vector. However, because std::vector requires a homogeneous list of elements, slicing occursThe most effective way to avoid slicing of objects is to ensure, whenever possible, that polymorphic base classes are abstract.

#include <iostream>
class#include Employee {
public:<string>
#include <vector>
 
void f(const std::vector<Employee> &v) {
  Employee(string theName) : name(theName) {};
  virtual ~Employee();
  string getName() const {return name;}
  virtual void print() const = 0;
private:
  string name;
};

...

for (const auto &e : v) {
    std::cout << e;
  }
}

int main() {
  Employee typist("Joe Smith");
  std::vector<Employee> v{typist, Employee("Bill Jones"), Manager("Jane Doe", typist)};
  f(v);
}

Compliant Solution

This compliant solution uses a vector of std::unique_ptr objects, which eliminates the slicing problem.

#include <iostream>
#include <memory>
#include <string>
#include <vector>

void f(const std::vector<std::unique_ptr<Employee>> &v) {
  for (const auto &e : v) {
    std::cout << *e;
  }
}

int main() {
  std::vector<std::unique_ptr<Employee>> v;
  
  v.emplace_back(new Employee("Joe Smith"));
  v.emplace_back(new Employee("Bill Jones"));
  v.emplace_back(new Manager("Jane Doe", *v.front()));
  
  f(v);
}

Risk Assessment

Slicing results in information being lostloss, which could lead to a program not working properly and hence to a abnormal program execution or denial-of-service attackattacks.

References

Automated Detection

Related Vulnerabilities

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

Related Guidelines

Bibliography

...

Image Added Image Added Image Added Wiki Markup\[[ISO/IEC 14882-2003|AA. C References#ISO/IEC 14882-2003]\] Section 9, "Classes" \[[Sutter 00|AA. C References#Sutter 00]\] GotW #22: "Object Lifetimes - Part I"