C++ Core Guidelines: Accessing Objects in a Hierarchy

There are nine rules to access objects in class hierarchies. Let’s have a closer look.



Here are the nine rules.

Accessing objects in a hierarchy rule summary:

Believe me. Slicing is an issue in a lot of C++ codebases.

C.145: Access polymorphic objects through pointers and references

If you access a virtual function, you don’t know which class provides the functionality; therefore, you should use a pointer or a reference. This means in the concrete example, that both d are sliced.

struct B{ 
  int a; 
  virtual int f(); 

struct D : B{ 
  int b; 
  int f() override; 

void use(B b)
    D d;
    B b2 = d;   // slice
    B b3 = b;

void use2()
    D d;
    use(d);   // slice


The first and the second slice cause only the B part of D to be copied.


Rainer D 6 P2 500x500Modernes C++ Mentoring

Be part of my mentoring programs:

  • "Fundamentals for C++ Professionals" (open)
  • "Design Patterns and Architectural Patterns with C++" (open)
  • "C++20: Get the Details" (open)
  • "Concurrency with Modern C++" (starts March 2024)
  • Do you want to stay informed: Subscribe.


    Do you want to know more about slicing? C.67: A base class should suppress copying, and provide a virtual clone instead if “copying” is desired talks about this issue.

    The three next rules are about dynamic_cast. Before I write about the dynamic_cast let me emphasise, casts, including dynamic_cast are used way too often. The job of the dynamic_cast is to “Safely converts pointers and references to classes up, down, and sideways along the inheritance hierarchy.” (

    C.146: Use dynamic_cast where class hierarchy navigation is unavoidable

    Here is the use case from the C++ Core Guidelines. You want to navigate in the class hierarchy.

    struct B {   // an interface
        virtual void f();
        virtual void g();
    struct D : B {   // a wider interface
        void f() override;
        virtual void h();
    void user(B* pb)
        if (D* pd = dynamic_cast<D*>(pb)) {      // (1)
            // ... use D's interface ...
        else {
            // ... make do with B's interface ...


    To detect the right type for pb (1) during run-time, a dynamic_cast is necessary. If the cast fails, you will get a null pointer.

    Because of performance reasons, you want to make the cast at compile-time; therefore, a static_cast is your friend. Now, you can violate the type of safety of the program.

    void user2(B* pb)   // bad
        D* pd = static_cast<D*>(pb);    // I know that pb really points to a D; trust me
        // ... use D's interface ...
    void user3(B* pb)    // unsafe
        if (some_condition) {
            D* pd = static_cast<D*>(pb);   // I know that pb really points to a D; trust me
            // ... use D's interface ...
        else {
            // ... make do with B's interface ...
    void f()
        B b;
        user(&b);   // OK
        user2(&b);  // bad error   (1)
        user3(&b);  // OK *if* the programmer got the some_condition check right (2)


    Casting a pointer to B to a pointer to D (1) is an error. This maybe holds for the last line (2).


    C.147: Use dynamic_cast to a reference type when failure to find the required class is considered an error

    If you make a dynamic_cast to a pointer, you will get, in the case of a failure a null pointer; but if you make a dynamic_cast to a reference, you will get a failure. To be more specific, you will get a std::bad_cast exception.

    // badCast.cpp
    struct A{
        virtual void f() {}
    struct B : A {};
    int main(){
        A a;
        B b;
        B* b1 = dynamic_cast<B*>(&a);  // nullptr, because 'a' is not a 'B'
        B& b2 = dynamic_cast<B&>(a);   // std::bad_cast, because 'a' is not a 'B' 


    The g++-6 compiler complains about both bad dynamic_cast’s and the run-time throws the expected exception in case of the reference.


    C.148: Use dynamic_cast to a pointer type when failure to find the required class is considered a valid alternative

    Sometimes it may be a valid option to choose an alternative code path, if the dynamic_cast to a pointer type fails and, therefore, returns a null pointer.

    C.149: Use unique_ptr or shared_ptr to avoid forgetting to delete objects created using new

    Using std::unique_ptr or std::shared_ptr is a very important but also quite an obvious rule to avoid resource leaks. If you build an application and not infrastructure such as a library, let me rephrase it: Never ever use new (and delete).

    Applying this rule means using std::make_unique and std::make_shared for creating smart pointers.

    C.150: Use make_unique() to construct objects owned by unique_ptrs, C.151: Use make_shared() to construct objects owned by shared_ptrs

    Both rules are pretty similar; therefore, I can handle them together. std::make_unique and std::make_shared give you the guarantee that the operation is never interleaved. That means in the following example: no memory leak can happen.

    f(std::make_unique<Foo>(), bar());


    This guarantee will not hold for the next call.

    f(std::unique_ptr<Foo>(new Foo()), bar());


    Foo may be at first allocated on the heap, and then bar is called. If bar throws an exception, Foo will not be destroyed, and we will get a memory leak.

    The same observation holds for std::make_share for creating a std::shared_ptrstd::make_shared has an additional performance benefit. Creating a std::shared_ptr requires two memory allocations; one for the resource and one for the counter. By using std::make_shared, both expensive allocations will happen in one step. The performance difference is dramatic. Look at my post: Memory and Performance Overhead of Smart Pointers.

    C.152: Never assign a pointer to an array of derived class objects to a pointer to its base

    This may not happen so often, but the consequences may be terrible if it happens. The result may be invalid object access or memory corruption. The former issue is shown in the example.

    struct B { int x; };
    struct D : B { int y; };
    D a[] = {{1, 2}, {3, 4}, {5, 6}};
    B* p = a;     // bad: a decays to &a[0] which is converted to a B*
    p[1].x = 7;   // overwrite D[0].y


    The last assignment should update the x attribute of an instance of B, but it overwrites the y attribute of a D. The reason is that B* was assigned a pointer to an array of derived objects D.

    Decay is the name of an implicit conversion that applies lvalue-to-rvalue, array-to-pointer, and function-to-pointer conversions removing const and volatile qualifiers. In the concrete example, you can call a function accepting a D* with an array of D‘s. The argument d of the following function will have a pointer to the first element of D. Valuable information, such as the length of the array of D‘s, is lost.

    void use(D* d);
    D d[] = {{1, 2}, {3, 4}, {5, 6}};

    C.153: Prefer virtual function to casting

    You can use dynamic_cast to simulate virtual behavior also often called late binding. But that is ugly and error-prone. You may get a null pointer or a std::bad_cast exception (see C.147). If you want to know more about virtual functions, read rule C67 in the post C++ Core Guidelines: Rules for Copy and Move.

    What’s next?

    In C++, we can overload functions, function templates, and even operators. In particular, operator overloading is often very controversial and discussed. For example, MISRA C++, a guideline for a safe subset of C++, forbids the overloading of operators. To be honest. I don’t see why? The C++ Core Guidelines have ten rules for overloading that will be the topic of my next post.





    Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Stephen Kelley, Kyle Dean, Tusar Palauri, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, Marco Parri Empoli, moon, Philipp Lenk, Hobsbawm, Charles-Jianye Chen, and Keith Jeffery.

    Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.

    My special thanks to Embarcadero
    My special thanks to PVS-Studio
    My special thanks to 
    My special thanks to Take Up Code
    My special thanks to SHAVEDYAKS


    I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.

    Standard Seminars (English/German)

    Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.

    • C++ – The Core Language
    • C++ – The Standard Library
    • C++ – Compact
    • C++11 and C++14
    • Concurrency with Modern C++
    • Design Pattern and Architectural Pattern with C++
    • Embedded Programming with Modern C++
    • Generic Programming (Templates) with C++
    • Clean Code with Modern C++
    • C++20

    Online Seminars (German)

    Contact Me

    Modernes C++ Mentoring,



    0 replies

    Leave a Reply

    Want to join the discussion?
    Feel free to contribute!

    Leave a Reply

    Your email address will not be published. Required fields are marked *