Do the advantages of using references over using pointers justify occasional "null-references"?

Question

I'm currently designing a class hierarchy that looks roughly like this:

struct Protocol
{
    // Pass lower-layer protocol as a reference.
    Protocol(Protocol & inLLProtocol) :
        mLLProtocol(inLLProtocol)
    {
    }

    // A protocol "always" has a LLProtocol.
    Protocol & mLLProtocol; 
};


struct Layer1Protocol : Protocol
{
    // This is the "bottom" protocol, so I pass a fake reference.
    Layer1Protocol() : Protocol(*static_cast<Protocol*>(nullptr)) {}
};

IIRC binding a reference to *nullptr is safe as long as the reference is never accessed. So it is now my responsibility design my Layer1Protocol class in such a way to prevent that.

I like this approach because I ensures that all user protocols instances will have a reference to their respective lower-layer protocol (Layer1Protocol being the exception, but it is part of the core library). I think this is preferable than working with pointers because once pointers are introduced then it becomes possible to pass null-pointers, which then may need to be checked at runtime, and the result is a lot of pointer checking code and occasional bugs.

Do you think my reference-based approach is defendable? Or is using null references always a bad practice?

Answer 1

Writing *static_cast<Protocol*>(nullptr) is dereferencing the nullptr, which invokes Undefined Behavior. You must never ever do that. The result can be anything Murphy feels up to. This might be what you call a "null reference", but it might just as well be that you (a male, AFAIK), get pregnant, while the program works as if you had dereferenced a valid pointer.

So, strictly speaking, there are no "null references". There's just Undefined Behavior.

Either your protocol class always and inevitably needs a lower level protocol, in which case you must not pass it a nullptr (not even disguised in a reference). Or it doesn't need a lower level protocol all the time, and has to check whether it has one before it can access it, in which case a pointer better implements your design constraints.

Answer 2

IIRC binding a reference to *nullptr is safe as long as the reference is never accessed.

No, dereferencing nullptr is always undefined behaviour. You cannot have a "null reference" in a correct program.

Answer 3

How is your approach different in any way to the equivalent approach that uses pointers, except for syntax and except for the fact that the pointer approach, unlike the reference approach, does not invoke UB?

If you're working with references to avoid having to check for null pointers but you're then passing (illegal) null references, you've negated that advantage of references. Now, your references can suddenly be null, so you will presumably need to check for that condition just like you would if you were using pointers.

If, as you say, you can guarantee that none of these null references will ever be dereferenced -- well, that same guarantee will hold if you use pointers.

Long story short: Pointers are not something to be avoided at all cost. If you have a situation where nulls can occur, you need to use pointers -- period. You seem to be worried about having to check for null pointers everywhere (presumably via assertions), but on most architectures, the MMU will stop you from dereferencing a null pointer anyway -- which is really almost as good as an assertion.

Answer 4

You might want to look at the "optional" class template from boost (I believe). It lets you pass an object but also lets you specify that you've deliberatly not provided any data in a slightly safer way than just a raw pointer.

It's not something I particularly like myself, but you might find it meets your requirements.