C ++中的多态性，子类型？

Question

can someone explain to me the last 5 lines , why that happen when Manager is sub-object to Employee ?

ostream& operator << (
   ostream &, const Employee &
);
Employee  e;
Manager   m;
Employee &eRef1 = e;  // OK!     
Employee &eRef2 = m;  // OK!  
Manager  &mRef1 = e;  // Compile error!
Manager  &mRef2 = m;  // OK!
cout << e << m;       // OK! 

Answer 1

That happens exactly because of what you said: Manager derives from Employee (I guess this is what you mean when you say " Manager is sub-object to Employee " ). This means all instances of Manager are also instances of Employee , but not vice versa.

Here, you are trying to bind a reference to a Manager to an object of type Employee . But since an instance of Employee is not an instance of Manager (that's the other way round!) you get an error.

If you want to understand why that's correct, try to think of what could happen if you did not get an error:

Employee e;
// ...
Manager& m = e; // This won't work, but let's suppose it did...
int s = m.get_size_of_managed_team(); // Huh?

If you could bind a reference to a Manager to an object which is not really a Manager , you may invoke functions for it that the actual object doesn't support. This would be chaos. Therefore, the compiler prevents this circumstance from arising at all.

Answer 2

References exhibit polymorphic behaviour. That is, you can have a reference to base class initialised with a derived class. However, you can't have a reference to derived class initialised with a base class.

Since Employee is the base of Manager , you cannot initialise a Manager reference with an employee. The rest of the initialisations are fine.

Reference | Initialised with | Valid?
----------|------------------|--------
Base&     | Base             | Yes
Base&     | Derived          | Yes
Derived&  | Base             | No
Derived&  | Derived          | Yes

This is intuitive. Why would you allow any Employee to hide under the disguise of a Manager ? Imagine working in a place like that - it'd be chaos!

Answer 3

In hierarchy like this, where classes are based off other classes, think of it this way.

A -> B -> C -> D

In that example, let -> mean B inherits from A, etc.

If you think of it that way, classes can morph into the classes less than them(to the left): D can become C, B, or A. For B, Classes to the right are not accessible, since they're "higher" up the chain, therefore you couldn't make B into a C, or D.

In your example,

Employee -> Manager

Managers can move left to Employee, so you can morph it that way, but Manager is to the RIGHT of Employee, which as said earlier, makes that transition impossible.

The reasoning is because, when you inherit, you gain all the benefits of the base class; variables, functions, all of it. When you try to go up the chain, you're adding variables, classes, etc, and you essentially have to re-create your object to do so, as it now takes more memory and will behave differently than originally. But, going down the tree, you're essentially just stripping an onion; taking off layers to reveal the spot of the onion you're after. They're all there to begin with, they're just not directly visible since they make up the smaller parts.