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 Employee { public: Employee(string theName) : name(theName) {}; string getName() const {return name;} virtual void print() const { cout << "Employee: " << getName() << endl; } private: string name; }; class Manager : public Employee { public: Manager(string theName, Employee theEmployee) : Employee(theName), assistant(theEmployee) {}; Employee getAssistant() const {return assistant;} virtual void print() const { cout << "Manager: " << getName() << endl; cout << "Assistant: " << assistant.getName() << endl; } private: Employee assistant; }; int main () { Employee coder("Joe Smith"); Employee typist("Bill Jones"); Manager designer("Jane Doe", typist); coder = designer; // slices Jane Doe! coder.print(); }
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 (Pointers)
Assuming 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 () { Employee *coder = new Employee("Joe Smith"); Employee *typist = new Employee("Bill Jones"); Manager *designer = new Manager("Jane Doe", *typist); coder = designer; coder->print(); }
Now, the object designer
is not sliced, and the output is:
Manager: Jane Doe Assistant: Bill Jones
Compliant Solution (Smart Pointers)
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.
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 }
Compliant Solution (References)
Alternatively, references may be used to refer to the various derived employee objects.
int main () { Employee coder("Joe Smith"); Employee typist("Bill Jones"); Manager designer("Jane Doe", typist); Employee &toPrint = designer; // Jane remains entire toPrint.print(); }
Compliant Solution (Abstract Base Class)
The most effective way to avoid slicing of objects is to ensure, whenever possible, that polymorphic base classes are abstract.
class Employee { public: Employee(string theName) : name(theName) {}; virtual ~Employee(); string getName() const {return name;} virtual void print() const = 0; private: string name; };
The presence of a pure virtual function in the Employee base class ensures that no objects of type Employee will exist, and slicing cannot occur.
Risk Assessment
Slicing results in information being lost, which could lead to a program not working properly and hence to a denial-of-service attack.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
OBJ33-CPP |
1 (low) |
2 (probable) |
1 (high) |
P2 |
L3 |
References
[[Dewhurst 02]] Gotcha #38, "Slicing"
[[ISO/IEC 14882-2003]] Section 9, "Classes"
[[Sutter 00]] GotW #22: "Object Lifetimes - Part I"
OBJ30-CPP. A class should not invoke its own virtual functions in its constructors or destructors. 13. Object Orientation (OBJ) OBJ34-CPP. Ensure the proper destructor is called for polymorphic objects