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:

C.145: Access polymorphic objects through pointers and references
C.146: Use dynamic_cast where class hierarchy navigation is unavoidable
C.147: Use dynamic_cast to a reference type when failure to find the required class is considered an error
C.148: Use dynamic_cast to a pointer type when failure to find the required class is considered a valid alternative
C.149: Use unique_ptr or shared_ptr to avoid forgetting to delete objects created using new
C.150: Use make_unique() to construct objects owned by unique_ptrs
C.151: Use make_shared() to construct objects owned by shared_ptrs
C.152: Never assign a pointer to an array of derived class objects to a pointer to its base
C.153: Prefer virtual function to casting

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.

Modernes C++ Mentoring

"Fundamentals for C++ Professionals" (open)

"Design Patterns and Architectural Patterns with C++" (open)

"C++20: Get the Details" (open)

"Concurrency with Modern C++" (open)

"Embedded Programming with Modern C++": January 2025

"Generic Programming (Templates) with C++": February 2025

"Clean Code: Best Practices for Modern C++": May 2025

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.” (http://en.cppreference.com/w/cpp/language/dynamic_cast)

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_ptr`s, C.151: Use `make_shared()` to construct objects owned by `shared_ptr`s

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_ptr. std::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}};

use(d);

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.

Post Views: 5,341

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, 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, Philipp Lenk, Charles-Jianye Chen, Keith Jeffery, Matt Godbolt, and Honey Sukesan.

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 Tipi.build
My special thanks to Take Up Code
My special thanks to SHAVEDYAKS