Modify a comment about Xeus cling not able to run a cell - it works with some...

Modify a comment about Xeus cling not able to run a cell - it works with some versions (it didn't on last that was working in macOS but does in the one in the Docker image).

Modify a comment about Xeus cling not able to run a cell - it works with some...
d74fae5e · GILLES Sebastien · f8d2ccd3 · d74fae5e · d74fae5e
Commit d74fae5e authored 4 years ago by GILLES Sebastien
--- a/1-ProceduralProgramming/6b-TP.ipynb
+++ b/1-ProceduralProgramming/6b-TP.ipynb
@@ -345,5 +345,5 @@
  }
 },
 "nbformat": 4,
- "nbformat_minor": 2
+ "nbformat_minor": 4
 }
--- a/2-ObjectProgramming/7-polymorphism.ipynb
+++ b/2-ObjectProgramming/7-polymorphism.ipynb
@@ -912,7 +912,7 @@
   "source": [
    "You may in fact explicitly tells the `c` pointer needs to be interpreted as a `PolymorphicThermicCar`:\n",
    "\n",
-    "**Xeus-cling issue:** Here cling doesn't manage to run it but it is accepted rightfully by a full-fledged compiler (see for instance [@Coliru](http://coliru.stacked-crooked.com/a/22fff15d28c93a17)):"
+    "**Xeus-cling issue:** Here cling may not be able to run it (depends on the version used) but it is accepted rightfully by a full-fledged compiler (see for instance [@Coliru](http://coliru.stacked-crooked.com/a/22fff15d28c93a17)):"
   ]
  },
  {

 %% Cell type:markdown id: tags:

 # [Getting started in C++](./) - [Object programming](./0-main.ipynb) - [Polymorphism](./7-polymorphism.ipynb)

 %% Cell type:markdown id: tags:

 <h1>Table of contents<span class="tocSkip"></span></h1>
 <div class="toc"><ul class="toc-item"><li><span><a href="#Polymorphism" data-toc-modified-id="Polymorphism-1">Polymorphism</a></span><ul class="toc-item"><li><span><a href="#Naïve-approach-to-underline-the-need" data-toc-modified-id="Naïve-approach-to-underline-the-need-1.1">Naïve approach to underline the need</a></span></li><li><span><a href="#virtual-keyword" data-toc-modified-id="virtual-keyword-1.2"><code>virtual</code> keyword</a></span></li><li><span><a href="#virtual-work-only-with-pointers-or-references" data-toc-modified-id="virtual-work-only-with-pointers-or-references-1.3"><code>virtual</code> work only with pointers or references</a></span></li><li><span><a href="#Abstract-class-and-pure-virtual-methods" data-toc-modified-id="Abstract-class-and-pure-virtual-methods-1.4">Abstract class and pure virtual methods</a></span></li><li><span><a href="#override-keyword" data-toc-modified-id="override-keyword-1.5">override keyword</a></span></li><li><span><a href="#Cost-of-virtuality" data-toc-modified-id="Cost-of-virtuality-1.6">Cost of virtuality</a></span></li></ul></li><li><span><a href="#dynamic_cast" data-toc-modified-id="dynamic_cast-2"><code>dynamic_cast</code></a></span></li><li><span><a href="#final-keyword" data-toc-modified-id="final-keyword-3"><code>final</code> keyword</a></span></li><li><span><a href="#Virtual-destructor-and-the-slicing-effect" data-toc-modified-id="Virtual-destructor-and-the-slicing-effect-4">Virtual destructor and the slicing effect</a></span><ul class="toc-item"><li><span><a href="#Good-practice:-should-my-destructor-be-virtual?" data-toc-modified-id="Good-practice:-should-my-destructor-be-virtual?-4.1">Good practice: should my destructor be virtual?</a></span></li></ul></li><li><span><a href="#Good-practice:-never-call-a-virtual-method-in-a-constructor" data-toc-modified-id="Good-practice:-never-call-a-virtual-method-in-a-constructor-5">Good practice: never call a virtual method in a constructor</a></span></li></ul></div>

 %% Cell type:markdown id: tags:

 ## Polymorphism

 ### Naïve approach to underline the need

 [So far](./6-inheritance.ipynb), I have not yet shown how objects could be stored in the same container, which was a justification I gave when introducing inheritance.

 The first idea would be to cram all items in a container which type is the base class:



 %% Cell type:code id: tags:

 ``` C++17
 #include <iostream>

 class NotPolymorphicVehicle
 {
    public:

        NotPolymorphicVehicle() = default;
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 #include <string>

 class NotPolymorphicCar : public NotPolymorphicVehicle
 {
    public:

        NotPolymorphicCar();

        void Print() const;
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 #include <iostream>

 void NotPolymorphicCar::Print() const
 {
    std::cout << "I'm a car!" << std::endl;
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 #include <string>

 class NotPolymorphicBicycle : public NotPolymorphicVehicle
 {
    public:

        NotPolymorphicBicycle();

        void Print() const;
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 #include <iostream>

 void NotPolymorphicBicycle::Print() const
 {
    std::cout << "I'm a bike!" << std::endl;
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 {
    NotPolymorphicBicycle b;
    NotPolymorphicCar c;

    NotPolymorphicVehicle list[2] = { b, c };
    list[0].Print(); // COMPILATION ERROR
 }
 ```

 %% Cell type:markdown id: tags:

 The issue here is that the objects are stored as `NotPolymorphicVehicle`, and this class doesn't know any method called `Print()`, even if all its children do.

 Defining `Print()` in the base class would not work either:

 %% Cell type:code id: tags:

 ``` C++17
 class AlsoNotPolymorphicVehicle
 {
    public:

        AlsoNotPolymorphicVehicle() = default;

        void Print() const;
 };

 class AlsoNotPolymorphicCar : public AlsoNotPolymorphicVehicle
 {
    public:

        AlsoNotPolymorphicCar() = default;

        void Print() const;
 };


 class AlsoNotPolymorphicBicycle : public AlsoNotPolymorphicVehicle
 {
    public:

        AlsoNotPolymorphicBicycle() = default;

        void Print() const;
 };

 ```

 %% Cell type:code id: tags:

 ``` C++17
 #include <iostream>

 void AlsoNotPolymorphicVehicle::Print() const
 {
    std::cout << "I am... hopefully a polymorphic vehicle?" << std::endl;
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 #include <iostream>

 void AlsoNotPolymorphicCar::Print() const
 {
    std::cout << "I'm a car!" << std::endl;
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 #include <iostream>

 void AlsoNotPolymorphicBicycle::Print() const
 {
    std::cout << "I'm a bike!" << std::endl;
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 #include <iostream>
 {
    AlsoNotPolymorphicBicycle b;
    AlsoNotPolymorphicCar c;

    AlsoNotPolymorphicVehicle list[2] = { b, c };

    for (auto i = 0ul; i < 2ul; ++i)
        list[i].Print(); // No compilation error, but clearly not what we intended...
 }
 ```

 %% Cell type:markdown id: tags:

 So far, the perspectives aren't rosy:

 * The base class needs to know all the methods beforehand: `Print()` had to be defined in the base class to make it compile.
 * And even so, the result was clearly not what we hoped for: the dumb value provided in the base class was actually returned.

 ### `virtual ` keyword

 The second point is easy to solve: there is a dedicated keyword named **virtual** in the language that may qualify a method and tell it is likely to be adapted or superseded in a derived class.

 Almost all methods might be virtual, with very few exceptions:

 * Static methods
 * Constructors: no constructor can be virtual, and even more than that using a virtual method within a constructor won't work as expected.
 * Methods with template arguments (we'll [come to that](../4-Templates/1-Intro.ipynb#Function-templates-(or-methods)) ...)

 That means even the destructor may be virtual (and probably should - we'll go back to that as well...).

 %% Cell type:code id: tags:

 ``` C++17
 class PolymorphicButClumsyVehicle
 {
    public:

        PolymorphicButClumsyVehicle() = default;

        virtual void Print() const;
 };

 class PolymorphicButClumsyCar : public PolymorphicButClumsyVehicle
 {
    public:

        PolymorphicButClumsyCar() = default;

        virtual void Print() const;
 };


 class PolymorphicButClumsyBicycle : public PolymorphicButClumsyVehicle
 {
    public:

        PolymorphicButClumsyBicycle() = default;

        virtual void Print() const;
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 #include <iostream>

 void PolymorphicButClumsyVehicle::Print() const // Please notice: no `virtual` on definition!
 {
    std::cout << "I am... hopefully a polymorphic vehicle?" << std::endl;
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 #include <iostream>

 void PolymorphicButClumsyCar::Print() const
 {
    std::cout << "I am a car!" << std::endl;
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 #include <iostream>

 void PolymorphicButClumsyBicycle::Print() const
 {
    std::cout << "I am a bike!" << std::endl;
 }
 ```

 %% Cell type:markdown id: tags:

 ### `virtual` work only with pointers or references

 %% Cell type:code id: tags:

 ``` C++17
 #include <iostream>
 {
    PolymorphicButClumsyBicycle b;
    PolymorphicButClumsyCar c;

    PolymorphicButClumsyVehicle list[2] = { b, c };

    for (auto i = 0ul; i < 2ul; ++i)
        list[i].Print(); // No compilation error, but clearly not what we intended...
 }
 ```

 %% Cell type:markdown id: tags:

 Still not what was intended... That's because when you use the objects directly as we do here, **static binding** is used: the definitions seen in the base class are used directly because the resolution occurs at compilation time.

 To use the **dynamic binding**, we need to use either references or pointers. Let's do that:

 %% Cell type:code id: tags:

 ``` C++17
 #include <iostream>
 {
    PolymorphicButClumsyVehicle* b = new PolymorphicButClumsyBicycle;
    PolymorphicButClumsyVehicle* c = new PolymorphicButClumsyCar;

    PolymorphicButClumsyVehicle* list[2] = { b, c };

    for (auto i = 0ul; i < 2ul; ++i)
        list[i]->Print();

    delete b;
    delete c;
 }
 ```

 %% Cell type:markdown id: tags:

 The fact that a `PolymorphicButClumsyVehicle` pointer is able to properly call the derived classes version is what is called **polymorphism**; it's at runtime that the decision to call `PolymorphicButClumsyVehicle::Print()` or `PolymorphicButClumsyCar::Print()` is taken.

 We're nonetheless not completely done yet:

 %% Cell type:code id: tags:

 ``` C++17
 #include <iostream>
 {
    PolymorphicButClumsyVehicle* v = new PolymorphicButClumsyVehicle;
    PolymorphicButClumsyVehicle* b = new PolymorphicButClumsyBicycle;
    PolymorphicButClumsyVehicle* c = new PolymorphicButClumsyCar;

    PolymorphicButClumsyVehicle* list[3] = { v, b, c };

    for (auto i = 0ul; i < 3ul; ++i)
        list[i]->Print(); // No compilation error, but clearly not what we intended...

    delete v;
    delete b;
    delete c;
 }
 ```

 %% Cell type:markdown id: tags:

 ### Abstract class and pure virtual methods

 Our issue here is that `PolymorphicButClumsyVehicle` has no business being instantiated directly: it is merely an **abstract class** which should never be instantiated but is there to provide a skeleton to more substantiated derived classes.

 The mechanism to indicate that is to provide at least one **pure virtual method**: a method which prototype is given in the base class but that **must** be overriden in derived classes (at least if you want them to become concrete). The syntax to do so is to add `= 0` after the prototype.

 %% Cell type:code id: tags:

 ``` C++17
 class PolymorphicVehicle
 {
    public:

        PolymorphicVehicle() = default;

        virtual void Print() const = 0; // the only change from PolymorphicButClumsyVehicle!
 };

 class PolymorphicCar : public PolymorphicVehicle
 {
    public:

        PolymorphicCar() = default;

        virtual void Print() const;
 };


 class PolymorphicBicycle : public PolymorphicVehicle
 {
    public:

        PolymorphicBicycle() = default;

        virtual void Print() const;
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 #include <iostream>

 void PolymorphicCar::Print() const
 {
    std::cout << "I am a car!" << std::endl;
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 #include <iostream>

 void PolymorphicBicycle::Print() const
 {
    std::cout << "I am a bike!" << std::endl;
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 {
    PolymorphicVehicle v; // Compilation error: you can't instantiate an abstract class!
 }
 ```

 %% Cell type:markdown id: tags:

 But the following is fine:

 %% Cell type:code id: tags:

 ``` C++17
 #include <iostream>
 {
    PolymorphicVehicle* b = new PolymorphicBicycle;
    PolymorphicVehicle* c = new PolymorphicCar;

    PolymorphicVehicle* list[2] = { b, c };

    for (auto i = 0ul; i < 2ul; ++i)
        list[i]->Print();

    delete b;
    delete c;
 }
 ```

 %% Cell type:markdown id: tags:

 **Beware:** You **must** provide a definition for all non pure-virtual methods in your class. Not doing so leads to a somewhat cryptic error at link-time.

 You are not required to provide a definition for a pure virtual method, and you won't most of the time... But you might provide one if you want to do so, for instance to provide an optional default instantiation for the method in derived classes:

 %% Cell type:code id: tags:

 ``` C++17
 struct VirtualBase
 {
     virtual void Method() = 0;
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 #include <iostream>

 void VirtualBase::Method()
 {
    std::cout << "Default implementation provided in abstract class." << std::endl;
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 struct Concrete1 : public VirtualBase
 {
    virtual void Method() override;
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 struct Concrete2 : public VirtualBase
 {
    virtual void Method() override;
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 void Concrete1::Method()
 {
    VirtualBase::Method(); // call to the method defined in the base class
    std::cout << "This enables providing a base behaviour that might be completed if needed "
        "in derived classes, such as here by these lines you are reading!" << std::endl;
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 void Concrete2::Method()
 {
    std::cout << "Overriden implementation." << std::endl;
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 {
    std::cout << "====== Concrete 1: uses up the definition provided in base class =====" << std::endl;
    Concrete1 concrete1;
    concrete1.Method();

    std::cout << "\n====== Concrete 2: doesn't use the definition provided in base class =====" << std::endl;
    Concrete2 concrete2;
    concrete2.Method();
 }
 ```

 %% Cell type:markdown id: tags:

 ### override keyword

 We saw in previous section that to make a method virtual we need to add a `virtual` qualifier in front of its prototype.

 I put it both in the base class and in the derived one, but in fact it is entirely up to the developer concerning the derived classes:

 %% Cell type:code id: tags:

 ``` C++17
 class European
 {
    public:

        European() = default;

        virtual void Print() const;
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 #include <iostream>

 void European::Print() const
 {
    std::cout << "I'm European!" << std::endl;
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 class French : public European
 {
    public:

        French() = default;

        void Print() const; // virtual keyword is skipped here - and it's fine by the standard
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 #include <iostream>

 void French::Print() const
 {
    std::cout << "I'm French!" << std::endl;
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 {
    European* european = new European;
    european->Print();

    European* french = new French;
    french->Print();
 }
 ```

 %% Cell type:markdown id: tags:

 But the drawback doing so is that we may forget the method is virtual... or we might do a typo when writing it! And in this case, the result is not what is expected:

 %% Cell type:code id: tags:

 ``` C++17
 class ThirstyFrench : public European
 {
    public:

        ThirstyFrench() = default;

        virtual void Pint() const; // typo here! And the optional `virtual` doesn't help avoid it...
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 void ThirstyFrench::Pint() const
 {
     std::cout << "I'm French!" << std::endl;
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 {
    ThirstyFrench* french = new ThirstyFrench;
    french->Print();
 }
 ```

 %% Cell type:markdown id: tags:

 What would be nice is for the compiler to provide a way to secure against such errors... and that exactly what C++ 11 introduced with the `override` keyword. This keyword explicitly says we are declaring an override of a virtual method, and the code won't compile if the prototype doesn't match:

 %% Cell type:code id: tags:

 ``` C++17
 class ThirstyButCarefulFrench : public European
 {
    public:

        ThirstyButCarefulFrench() = default;

        void Pint() const override; // COMPILATION ERROR!
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 class ForgetfulFrench : public European
 {
    public:

        ForgetfulFrench() = default;

        virtual void Print() override; // COMPILATION ERROR! `const` is missing and therefore prototype doesn't match.
 };
 ```

 %% Cell type:markdown id: tags:

 ### Cost of virtuality

 You have to keep in mind there is a small cost related to the virtual behaviour: at each method call the program has to figure out which dynamic type to use. To be honest the true effective cost is quite blurry for me: some says it's not that important (see for instance [isocpp FAQ](https://isocpp.org/wiki/faq/virtual-functions)) while others will say you can't be serious if you're using them. I tend personally to avoid them in the part of my code where I want to crunch numbers fast and I use them preferably in the initialization phase.



 ## `dynamic_cast`

 There is yet a question to ask: what if we want to use a method only defined in the derived class? For instance, if we add an attribute `oil_type_` that is not meaningful for all types of vehicles, can we access it?

 %% Cell type:code id: tags:

 ``` C++17
 #include <string>

 class PolymorphicVehicle
 {
    public:

        PolymorphicVehicle() = default;

        virtual void Print() const = 0;
 };



 class PolymorphicThermicCar : public PolymorphicVehicle
 {
    public:

        PolymorphicThermicCar(std::string&& oil_type);

        virtual void Print() const;

        const std::string& GetOilType() const;

    private:

        std::string oil_type_;
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 PolymorphicThermicCar::PolymorphicThermicCar(std::string&& oil_type)
 : PolymorphicVehicle(),
 oil_type_(oil_type)
 { }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 #include <iostream>
 void PolymorphicThermicCar::Print() const
 {
    std::cout << "I'm a car that uses up " << GetOilType() << std::endl;
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 const std::string& PolymorphicThermicCar::GetOilType() const
 {
    return oil_type_;
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 #include <iostream>

 {
    PolymorphicVehicle* c = new PolymorphicThermicCar("gazole");
    std::cout << "Oil type = " << c->GetOilType() << std::endl; // COMPILATION ERROR: been there before...
 }
 ```

 %% Cell type:markdown id: tags:

 You may in fact explicitly tells the `c` pointer needs to be interpreted as a `PolymorphicThermicCar`:

-**Xeus-cling issue:** Here cling doesn't manage to run it but it is accepted rightfully by a full-fledged compiler (see for instance [@Coliru](http://coliru.stacked-crooked.com/a/22fff15d28c93a17)):
+**Xeus-cling issue:** Here cling may not be able to run it (depends on the version used) but it is accepted rightfully by a full-fledged compiler (see for instance [@Coliru](http://coliru.stacked-crooked.com/a/22fff15d28c93a17)):

 %% Cell type:code id: tags:

 ``` C++17
 // Xeus-cling issue!

 #include <iostream>

 {
    PolymorphicThermicCar* c = new PolymorphicThermicCar("gazole");

    PolymorphicVehicle* list[1] = { c }; // Ok!

    auto c_corrected = dynamic_cast<PolymorphicThermicCar*>(list[0]);

    std::cout << "Oil type = " << c_corrected->GetOilType() << std::endl;
 }
 ```

 %% Cell type:markdown id: tags:

 So you could devise a way to identify which is the dynamic type of your `PolymorphicVehicle` pointer and cast it dynamically to the rightful type so that extended API offered by the derived class is accessible.

 If you find this clunky, you are not alone: by experience if you really need to resort to **dynamic_cast** it's probably your data architecture needs some revision. But maybe the mileage vary for other developers, and it's useful to know the possibility exists.

 %% Cell type:markdown id: tags:

 ## `final` keyword

 If you need to specify a class that can't be derived, you may stick a `final` keyword in its declaration (from C++11 onward):

 %% Cell type:code id: tags:

 ``` C++17
 class UnderivableClass final
 { };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 class ITryAnyway : public UnderivableClass // COMPILATION ERROR!
 { };
 ```

 %% Cell type:markdown id: tags:

 The keyword may also be used only for one or several virtual methods:

 %% Cell type:code id: tags:

 ``` C++17
 struct DerivableClass
 {
    virtual void Method1();
    virtual void Method2();
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 struct DerivedClassFirstLevel : public DerivableClass
 {
    virtual void Method1() override final;
    virtual void Method2() override;
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 struct DerivedClassSecondLevel : public DerivedClassFirstLevel
 {
    virtual void Method2() override; // ok
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 struct DerivedClassSecondLevelIgnoreFinal : public DerivedClassFirstLevel
 {
    virtual void Method1() override; // COMPILATION ERROR!
 };
 ```

 %% Cell type:markdown id: tags:

 ## Virtual destructor and the slicing effect

 I indicated earlier that destructors might be virtual, but in fact I should have said than for most of the non final classes the destructor should be virtual:

 %% Cell type:code id: tags:

 ``` C++17
 struct BaseClass3
 {
    BaseClass3();

    ~BaseClass3();
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 #include <string>
 #include <iostream>

 BaseClass3::BaseClass3()
 {
    std::cout << "BaseClass3 constructor" << std::endl;
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 BaseClass3::~BaseClass3()
 {
    std::cout << "BaseClass3 destructor" << std::endl;
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 struct DerivedClass3 : public BaseClass3
 {
    DerivedClass3();

    ~DerivedClass3();
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 DerivedClass3::DerivedClass3()
 {
    std::cout << "DerivedClass3 constructor" << std::endl;
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 DerivedClass3::~DerivedClass3()
 {
    std::cout << "DerivedClass3 destructor" << std::endl;
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 {
    std::cout << "Here all should be well: " << std::endl;
    {
        DerivedClass3 obj;
    }

    std::cout << std::endl << "But there not so much, see the missing destructor call! " << std::endl;

    {
        BaseClass3* obj = new DerivedClass3;
        delete obj;
    }

 }
 ```

 %% Cell type:markdown id: tags:

 You can see here the derived class destructor is not called! This means if you're for instance deallocating memory in this destructor, the memory will remain unduly allocated.

 To circumvent this, you need to declare the destructor virtual in the base class. This way, the derived destructor will be properly called.

 This is what is called the **slicing effect**.

 ### Good practice: should my destructor be virtual?

 So to put in a nutshell, 99 % of the time:

 * If a class of yours is intended to be inherited from, make its destructor virtual.
 * If not, mark it as final.

 %% Cell type:markdown id: tags:

 ## Good practice: never call a virtual method in a constructor

 A very important point: I lost time years ago with this because I didn't read carefully enough item 9 of \cite{Meyers2005}...

 Due to the way construction occurs, never call a virtual method in a constructor: it won't perform the dynamic binding as you would like it to.


 %% Cell type:code id: tags:

 ``` C++17
 #include <string>

 struct BaseClass4
 {
    BaseClass4();

    virtual std::string ClassName() const;
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 struct DerivedClass4 : public BaseClass4
 {
    DerivedClass4() = default;

    virtual std::string ClassName() const;
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 #include <iostream>

 BaseClass4::BaseClass4()
 {
    std::cout << "Hello! I'm " << ClassName() << std::endl;
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 std::string BaseClass4::ClassName() const
 {
    return "BaseClass4";
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 std::string DerivedClass4::ClassName() const
 {
    return "DerivedClass4";
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 {
    DerivedClass4 object; // not working by stack allocation...

    DerivedClass4* object2 = new DerivedClass4; // neither by heap allocation!
 }
 ```

 %% Cell type:markdown id: tags:

 There is unfortunately no way to circumvent this; just some hack tactics (see for instance the _VirtualConstructor_ idiom on the [isocpp FAQ](https://isocpp.org/wiki/faq/virtual-functions)).

 When I need this functionality, I usually define an `Init()` method to call after the constructor, which includes the calls to virtual methods:

 %% Cell type:code id: tags:

 ``` C++17
 #include <string>

 struct BaseClass5
 {
    BaseClass5() = default;

    void Init();

    virtual std::string ClassName() const;
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 struct DerivedClass5 : public BaseClass5
 {
    DerivedClass5() = default;

    virtual std::string ClassName() const;
 };
 ```

 %% Cell type:code id: tags:

 ``` C++17
 #include <iostream>

 void BaseClass5::Init()
 {
    std::cout << "Hello! I'm " << ClassName() << std::endl;
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 std::string BaseClass5::ClassName() const
 {
    return "BaseClass5";
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 std::string DerivedClass5::ClassName() const
 {
    return "DerivedClass5";
 }
 ```

 %% Cell type:code id: tags:

 ``` C++17
 {
    DerivedClass5 object; // nope by stack allocation
    object.Init();

    DerivedClass5* object2 = new DerivedClass5; // same by heap allocation
    object2->Init();
 }
 ```

 %% Cell type:markdown id: tags:

 But it's not perfect either: if the end-user forget to call the `Init()` method the class could be ill-constructed (to avoid this either I provide manually a check mechanism or I make sure the class is private stuff not intended to be used directly by the end-user).

 %% Cell type:markdown id: tags:

 # References

 (<a id="cit-Meyers2005" href="#call-Meyers2005">Meyers, 2005</a>) Scott Meyers, ``_Effective C++: 55 Specific Ways to Improve Your Programs and Designs (3rd Edition)_'',  2005.


 %% Cell type:markdown id: tags:

 © _CNRS 2016_ - _Inria 2018-2021_
 _This notebook is an adaptation of a lecture prepared by David Chamont (CNRS) under the terms of the licence [Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)](http://creativecommons.org/licenses/by-nc-sa/4.0/)_
 _The present version has been written by Sébastien Gilles and Vincent Rouvreau (Inria)_