class Person {

}

class Employee {
public:
  Person* GetPerson();
private:
  Person *person;
}

class Student {
public:
  Person* GetPerson();
private:
  Person *person;
}

A dynamic cast can be easily converted to a virtual function. For every "dynamic_cast<X*>", make a virtual function "X* GetX()", which returns "nullptr" in the base class, and "this" in the X class, eg (leaving out the declarations, constructors, etc).

This could work if all possible implementations of the class are known at compile / link time, but this is not the case in general.

A dynamic cast can be easily converted to a virtual function. For every "dynamic_cast<X*>", make a virtual function "X* GetX()", which returns "nullptr" in the base class, and "this" in the X class, eg (leaving out the declarations, constructors, etc).

class A {
    virtual B* GetB() { return nullptr; };
    virtual C* GetC() { return nullptr; };
};

class B : public A {
    virtual B* GetB() { return this; };
};

class C : public A {
    virtual C* GetC() { return this; };
};

Of course, the idea hasn't improved at all even if you code it in virtual functions.

For the above reason, I don't think dynamic_cast would be extremely expensive compared to virtual functions. A compiler could add this kind of code.



@Matias Goldberg

if( basePtr->getType() = DERIVED_TYPE )

That should be 2 '=' signs there

A person is not composed of a student or an employee

No, A student and an employee are composed of a person. A student instance and an employee instance might share the same person.

Claiming this scenario is better suited for a composition approach breaks one of the very first things you learn about composition and inheritance.

The first rule of inheritance is: prefer using composition by default, and use inheritance only when necessary.

Creating virtual functions to inherit from to complete a task may work when the Employee or Student have specific tasks that the consumer is delegating, but what if the consumer needs information from those classes to perform a job that the Student or Employee have no knowledge of(and should not). What if the consumer is the school that the Student attends and the Employee work at? The school needs to get information from these two separate classes to file a tax return to the Government(or what ever arbitrary example you want to use).

If the algorithm has to change it's behaviour depending on the specific derived type hiding behind the common interface, then that is a sign that the Liskov substitution principle has been violated, so inheritance was not a valid choice in the first place. That is not a valid OO design.

What if you want to keep expanding on the Person list and add a SecurityPersonnel object to the list? Or further go down and start subclassing Employee into Teacher, GymTeacher ect... In this case, inheritance sounds like the logical thing to do here.

No, as above, it breaks the rules of OOD and is unecessary. Also, what do you do when a student gains a job as a lecturer, while still studying? Do you delete their Student instance and replace it with a StudentAndEmployee instance that makes use of multiple inheritance?
This example is the text book example of inheritance abuse...