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 there is insufficient space within the base class in which to store them. This act is commonly referred to as slicing the object as 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. This results in slicing the Manager objects, 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.

class#include Employee<iostream>
#include {<string>
public:
 class Employee(string theName) : name(theName) {};
  std::string getName() const {return name;}Name;
  
protected:
  virtual void print(std::ostream &OS) const {
    coutOS << "Employee: " << getName() << std::endl;      
  }
private  
public:
  Employee(const std::string name;
};

class Manager : public Employee {
public:
  Manager(string theName, Employee theEmployee) : &Name) : Name(Name) {}
  const std::string &getName() const { return Name; }
  friend std::ostream &operator<<(std::ostream &OS, const Employee &E) {
    EmployeeE.print(theName), assistant(theEmployee) {};
  Employee getAssistant() const {return assistant;}
  virtualOS);
    return OS;
  }
};
 
class Manager : public Employee {
  Employee Assistant;
  
protected:
  void print(std::ostream &OS) const override {
    coutOS << "Manager: " << getName() << std::endl;
    coutOS << "Assistant: " << assistant.getNamestd::endl << "\t" << getAssistant() << std::endl;      
  }
private:
  
public:
  Manager(const std::string &Name, const Employee &Assistant) : Employee(Name), Assistant(Assistant) {}
  const Employee assistant;
};&getAssistant() const { return Assistant; }
};

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

int main () {
  Employee coderCoder("Joe Smith");
  Employee typistTypist("Bill Jones");
  Manager designerDesigner("Jane Doe", typistTypist);

  coder
 = designerf(Coder);
  // 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 When f() is called with the Designer argument, the formal parameter in f() is sliced and information is lost. Thus, when the Employee object is printed, Employee::Print() is called instead of Manager::Print(), resulting in the output:

Employee: Jane Doe

...

Doe

...

Compliant Solution (Pointers)

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

int mainvoid f(const Employee *E) {
  if (E) {
  Employee *coder = new Employee  std::cout << *E;
  }
}

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

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

This compliant solution also complies with EXP34-C. Do not dereference null pointers in the implementation of f(). With this definition, the output becomes:

Employee: Joe Smith
Employee: Bill Jones

Manager: Jane Doe
Assistant: 
	Employee: Bill Jones

Compliant Solution (

...

References)

Alternatively, it is often safer to use a smart pointer, like std::auto_ptr, to hold the address of allocated memory. This is typically more robust than the use of raw pointers.An improved compliant solution, which does not require guarding against null pointers within f(), uses references instead of pointers:

int main (void f(const Employee &E) {
  auto_ptr<Employee> coder( new Employeestd::cout << E;
}

int main() {
  Employee Coder("Joe Smith") );
  auto_ptr<Employee> typist( new EmployeeEmployee Typist("Bill Jones") );
  auto_ptr<Manager>Manager designerDesigner( new Manager("Jane Doe", *typist) Typist);

  coder
 = designer; // Smith deleted, Doe xferredf(Coder);
  coder->printf(Typist);
  // everyone deletedf(Designer);
}

Compliant Solution (References)

Noncompliant Code Example

This noncompliant code example uses the same class definitions of Employee and Manager from above, and attempts to store Employee objects in a std::vector. However, because std::vector requires a homogeneous list of elements, slicing occurs.Alternatively, references may be used to refer to the various derived employee objects.

// In addition to the #includes from the previous example.
#include <vector>
 
void f(const std::vector<Employee> &V) {
  for (const auto &E : V) {
    std::cout << E;
  }
}

int main () {
  Employee coderTypist("Joe Smith");
  Employee typiststd::vector<Employee> V{Typist, Employee("Bill Jones");
 , Manager designer("Jane Doe", typistTypist)};

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

Compliant Solution

...

This compliant solution stores std::unique_ptr smart pointers in the std::vector, which eliminates the slicing problem:The most effective way to avoid slicing of objects is to ensure, whenever possible, that polymorphic base classes are abstract.

Code Block
bgColor #ccccff lang cpp
class Employee { public: Employee(string theName) : name(theName) {}; virtual ~Employee(); string getName() const {return name;} virtual void print() const = 0; private: string name; };

...

// In addition to the #includes from the previous example. #include <memory> #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 lost, which could lead to a program not working properly and hence to a denial-of-service attackabnormal program execution or denial of service attacks.

Automated Detection

Related Vulnerabilities

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

Related Guidelines

Bibliography

...

...