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.
| Code Block | ||||
|---|---|---|---|---|
| ||||
#include <iostream>
#include <string>
class Employee {
std::string Name;
protected:
virtual void print(std::ostream &OS) const {
OS << "Employee: " << getName() << std::endl;
}
public:
Employee(const std::string &Name) : Name(Name) {}
const std::string &getName() const { return Name; }
friend std::ostream &operator<<(std::ostream &OS, const Employee &E) {
E.print(OS);
return OS;
}
};
class Manager : public Employee {
Employee Assistant;
protected:
void print(std::ostream &OS) const override {
OS << "Manager: " << getName() << std::endl;
OS << "Assistant: " << std::endl << "\t" << getAssistant() << std::endl;
}
public:
Manager(const std::string &Name, const Employee &Assistant) : Employee(Name), Assistant(Assistant) {}
const Employee &getAssistant() 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);
f(Typist);
f(Designer);
}
|
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:
| Code Block |
|---|
Employee: Jane Doe |
Compliant Solution (Pointers)
Using the same class definitions as above, this compliant solution modifies the definition of f() to require raw pointers to the object, removing the slicing problem:
| Code Block | ||||
|---|---|---|---|---|
| ||||
void f(const Employee *E) {
if (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);
}
|
This compliant solution also complies with EXP34-C. Do not dereference null pointers in the implementation of f(). With this definition, the output becomes:
| Code Block |
|---|
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:
| Code Block | ||||
|---|---|---|---|---|
| ||||
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 of the 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. 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 requires the Manager object to not attempt to copy-initialize its Employee object, which subtly changes the semantics of the class hierarchy.
| Page properties | ||
|---|---|---|
| ||
I'm not entirely happy with this CS because it now has the chance to use a dangling reference to an All told, I think the examples need a bit more love. |
| Code Block | ||||
|---|---|---|---|---|
| ||||
#include <iostream>
#include <string>
class Noncopyable {
Noncopyable(const Noncopyable &) = delete;
void operator=(const Noncopyable &) = delete;
protected:
Noncopyable() = default;
};
class Employee : Noncopyable {
std::string Name;
protected:
virtual void print(std::ostream &OS) const {
OS << "Employee: " << getName() << std::endl;
}
public:
Employee(const std::string &Name) : Name(Name) {}
const std::string &getName() 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: this definition has been modified
protected:
void print(std::ostream &OS) const override {
OS << "Manager: " << getName() << std::endl;
OS << "Assistant: " << std::endl << "\t" << getAssistant() << std::endl;
}
public:
Manager(const std::string &Name, const Employee &Assistant) : Employee(Name), Assistant(Assistant) {}
const Employee &getAssistant() 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);
f(Coder);
f(Typist);
f(Designer);
} |
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.
| Code Block | ||||
|---|---|---|---|---|
| ||||
// 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 Typist("Joe Smith");
std::vector<Employee> V{Typist, Employee("Bill Jones"), Manager("Jane Doe", Typist)};
f(V);
} |
Compliant Solution
This compliant solution stores std::unique_ptr smart pointers in the std::vector, which eliminates the slicing problem:
| Code Block | ||||
|---|---|---|---|---|
| ||||
// 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 abnormal program execution or denial of service attacks.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
OOP51-CPP | Low | Probable | Medium | P4 | L3 |
Automated Detection
Tool | Version | Checker | Description | ||||||
|---|---|---|---|---|---|---|---|---|---|
| 3072,3073 |
Related Vulnerabilities
Search for other vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
| CERT C++ Coding Standard | CTR56-CPP. Do not use pointer arithmetic on polymorphic objects |
| CERT C Coding Standard |
Bibliography
| [ISO/IEC 14882-2014] | 12.8, "Copying and Moving Class Objects" |
| [Dewhurst 02] | Gotcha #38, "Slicing" |
| [Sutter 00] | GotW #22: "Object Lifetimes - Part I" |