Calling member function on a nullptr in C++

Welcome to the next pikoTutorial!

nullptr and the segmentation fault

One of the first things that beginner C++ programmers realize after starting to play around with pointers is that dereferencing a nullptr leads to an immediate program crash caused by the segmentation fault. This leads to a common belief that whenever someone tries to call a member function on a nullptr, the program will immediately terminate. This is however not true and you can check it by yourself running the following code:

C++

#include <iostream>
#include <memory>

class MyClass
{
public:
    void PrintHello()
    {
        std::cout << "Hello" << std::endl;
    }
};

int main()
{
    std::shared_ptr<MyClass> nullptr_instance = nullptr;
    
    nullptr_instance->PrintHello();
}

#include <iostream>
#include <memory>

class MyClass
{
public:
    void PrintHello()
    {
        std::cout << "Hello" << std::endl;
    }
};

int main()
{
    std::shared_ptr<MyClass> nullptr_instance = nullptr;
    
    nullptr_instance->PrintHello();
}

Depending on the compiler you use, this code not only doesn’t crash, but also works as expected, so we see “Hello” being printed, although I explicitly called a member function on a null pointer.

Note for beginners: This is one of the examples of undefined behavior in C++. Although the above example works, you should never rely on such mechanisms in the production code because there’s no guarantee that it will work in all scenarios. Undefined behavior means simply that the C++ standard doesn’t specify what happens. The result could be anything, from working as expected to crashing your program, or even producing unexpected and erroneous results.

Why it works?

The reason is that in C++ a non-virtual member function is just a regular function with an implicit this pointer passed as its first argument. When you call nullptr_instance->PrintHello(), the function is called with nullptr_instance (which is nullptr in this case) as this pointer. However, since the function doesn’t use any member variables, it doesn’t dereference this pointer internally, so no segmentation fault occurs.

When it fails?

Look at the second example which is almost identical as the first one, but now MyClass derives from a base class and PrintHello() function is virtual.

C++

#include <iostream>
#include <memory>

class Interface
{
public:
    virtual void PrintHello() = 0;
};

class MyClass : public Interface
{
public:
    void PrintHello() override
    {
        std::cout << "Hello" << std::endl;
    }
};

int main()
{
    std::shared_ptr<MyClass> nullptr_instance = nullptr;
    
    nullptr_instance->PrintHello();
}

#include <iostream>
#include <memory>

class Interface
{
public:
    virtual void PrintHello() = 0;
};

class MyClass : public Interface
{
public:
    void PrintHello() override
    {
        std::cout << "Hello" << std::endl;
    }
};

int main()
{
    std::shared_ptr<MyClass> nullptr_instance = nullptr;
    
    nullptr_instance->PrintHello();
}

This time the program ends up with the segmentation fault because when you call nullptr_instance->PrintHello(), dynamic dispatch is required. In dynamic dispatch, the compiler uses a virtual table (vtable) to find the actual function to call at runtime based on the runtime type of the object.

However, since nullptr_instance is null, the pointer to the vtable (which is part of the object’s memory) is also null. When the program tries to access the vtable through the null pointer, this results in a null pointer dereference, causing the program to crash.

Read also: