For one, the copy constructor is expected by the compiler to be that way. The reason behind it is that a copy constructor would invoke itself if it accepted the copy source by value, resulting in an endless copy loop.

As Human, Lion, and Whale are all mammals and essentially fulfill an is-a relationship, you should use public inheritance where class Mammal is the base class, and others such as class Human, Lion, and Whale inherit from it.

Essentially none. These are both used to imply a class that derives-that is,specializes-a base class.

No. The compiler always ensures that the most restrictive of the applicable access specifiers is in force. Irrespective of the nature of inheritance, private members of a class are never accessible outside the class. An exception to this rule applies to classes and functions that have been declared as a friend.

Without the virtual keyword, you are not able to ensure that someone calling objBase.Function() will be redirected to Derived::Function(). Besides, compilation of code is not the only measure of its quality.

To store function pointers that ensure that the right version of a virtual function is invoked.

Ideally yes. Only then can you ensure that when someone does a
Base* pBase = new Derived();
delete pBase;
delete on a pointer of type Base* results in the destructor ~Derived() being invoked. This occurs when destructor ~Base() is declared virtual.

The ABC is not meant to be instantiated as a standalone object; rather it is always meant to be derived from. It contains pure virtual functions that define the minimal blueprint of functions that deriving classes need to implement, thus taking the role of an interface.

It is enough to declare a function as virtual once, but that declaration has to be in the base class.

Sure you can. Remember that you still cannot instantiate an ABC (Abstract Base Class) as it has at least one pure virtual function that needs to be implemented by a deriving class.