Gotcha #30: Slicing

class Employee { 
 public:
   virtual ~Employee();
   virtual void pay() const;
   // . . .
 protected:
   void setType( int type )
       { myType_ = type; }
 private:
   int myType_; // bad idea, see Gotcha #69
};
class Salaried : public Employee {
   // . . .
};
Employee employee;
Salaried salaried;
employee = salaried; // slice!

The assignment of salaried to employee is perfectly legal, since a Salaried is-a Employee, but the result is probably not what we wanted. After the assignment, the behavior of employee, both of its virtual and nonvirtual functions, will be Employee behavior. Additionally, any Salaried-specific data members will not be copied.

Most damaging, however, is that the state of employee will be a copy of the Employee part of salaried. What's wrong with that? Well, a derived Salaried object may use its Employee base class part to store Salaried-appropriate values that may not make sense in the context of an Employee object (see Gotcha #91).

As an illustration, suppose classes derived from Employee were to store some sort of type identification code in their Employee subobject. (Please note that this is not actually good design practice; it's just an illustration. See Gotcha #69.) After the slice, employee will behave like an Employee but will claim to be a Salaried.

In actual practice, the disconnect between the state of the sliced object and its behavior tends to be much more subtle and therefore much more damaging.

The most common source of slicing occurs when a derived class object is passed by value to initialize a base class formal parameter:

void fire( Employee victim ); 
// . . .
fire( salaried ); // slice!

This problem can be avoided through passing by reference (or pointer) instead of by value. In that case, no slicing will occur, since the derived class object is not actually copied and the formal argument is simply an alias for the actual argument (see Gotcha #5):

void rightSize( Employee &asset ); 
// . . .
rightSize( salaried ); // no slice

Other slicing problems are also possible, though less common. For example, it's possible to copy a base class subobject from one derived class object to another derived class object of a different type:

Employee *getNextEmployee(); // get an object derived from Employee 
// . . .
Employee *ep = getNextEmployee();
*ep = salaried; // slice!

Problems with slicing generally indicate deeper design flaws in a hierarchy. The best and simplest way to avoid slicing problems is to avoid concrete base classes (see Gotcha #93):

class Employee { 
 public:
   virtual ~Employee();
   virtual void pay() const = 0;
   // . . .
};
void fire( Employee ); // error, fortunately
void rightSize( Employee & ); // OK
Employee *getNextEmployee(); // OK
Employee *ep = getNextEmployee(); // OK
*ep = salaried; // error, fortunately
Employee e2( salaried ); // error, fortunately

An abstract base class can't be instantiated, so most situations that could lead to slicing will be caught at compile time.

Note that in rare situations, slicing is used intentionally in an implementation to modify the behavior or type of a derived class object. Typically, no data are sliced off, and slicing is used to "reinterpret" the base class data with different derived class behaviors. These techniques are useful but rare and should never be exposed as part of a general-purpose interface.