How to prevent an object from being deleted in places where it shouldn't, at compile-time?

Question

I have classes Graph and Algorithm:

class Graph
{
...
};

class Algorithm
{
...
private:
Graph * mGraph;
...
};

I want my algorithm to be able to do everything with mGraph except deleting it. I.e. I want to detect (at compile time) if somewhere in algorithm I'm deleting the graph. Is there a good (elegant) way to do such a thing? (The only way I realized is making Graphs destructor private so only friend classes have permission to delete it)

Answer 1

As others have pointed out, you cannot guard against malicious users of Graph. I'll assume that you don't want to, either, and that you're in the position of the Graph author trying to prevent users of the class from misunderstanding the ownership semantics of Graph while implementing Algorithm(s).

You could hand out only shared_ptr<Guard> by using the Named Constructor Idiom, which should prevent all but the most clueless of coders from attempting to delete Graph, however, Algorithm writers could still use Graph * mGraph as a member variable and pass shared_ptr<>::get() when constructing it...

To make this watertight for all but the most determined of malicious coders, you need to use the Counted Body Idiom. In short: wrap Graph*s with a GraphHandle class that is passed by-value and proxies Graph's API. It's a bit like only ever creating shared_ptr<Graph>s, but it prevents access to the raw pointer:

class Graph {
public:
    // ...
    void doSomething();
};

class GraphHandle {
    shared_ptr<Graph> graph;
public:
    explicit GraphHandle( const shared_ptr<Graph> & graph )
        : graph( graph )
    {
        assert( graph );
    }
    // do NOT provide an accessor for this->graph!
    // proxied API:
    void doSomething() {
        graph->doSomething();
    }
    // ...
};

class Algorithm {
    // ...
    GraphHandle graph;
};

This way, Algorithm can no longer delete the Graph.

Algorithm authors can of course still use Graph directly. To prevent this, make Graph private API and hide it completely behind GraphHandle. You can see this in production in the DOM implementation of Qt.

As an aside:

Using shared_ptr in the implementation of GraphHandle doesn't mean GraphHandle necessarily owns the Graph. You can hold a shared_ptr<Graph> outside of the GraphHandle, or, if the rest of the code uses naked pointers, you can just pass nodelete as the shared_ptrs deleter:

struct nodelete {
    template <typename T>
    void operator()( T* ) {}
};

// ...
Graph * nakedGraph = ...;
const shared_ptr<Graph> sharedGraph( nakedGraph, nodelete() );
GraphHandle handledGraph( sharedGraph );

Answer 2

You can't stop a malicious user from wreaking havoc, and your energies would be better spent documenting and educating users of the Graph class on how it should be used.

Raw pointers are used in many different ways, so not using a raw pointer would help self-document the expected lifetime. A reference may be appropriate in this case, since it sounds like 1) the lifetime is completely managed outside of the Algorithm class, and 2) Algorithm doesn't need to change which Graph it has. Otherwise a smart pointer may be appropriate, depending on what the actual lifetime is expected to be.

However, since mGraph is private, its presence can be completely encapsulated within Algorithm. Then all you need to do is document Algorithm's class invariant (which you should be doing anyway) and clearly specify that mGraph should not be deleted. Relatively few people should be touching Algorithm's internals (usually fewer than use the public interface), and they are expected to know the details of how Algorithm is implemented.

Docs and comments are the often overlooked, yet often most powerful tool we have against code misuse.

Answer 3

You could give Graph a private operator delete and friend the classes that are allowed to delete it. See here for information on making it private: Which operator delete?

The friended class could be a custom deleter you could give to a smart pointer (like boost::shared_ptr).

Answer 4

Making Graph's destructor private would indeed stop it from being deleted by Algorithm.

You can't make Graph's pointer const, as you can delete through const pointers.

If you held a reference to Graph, you could only call its destructor by jumping through hoops:

Graph* graphPtr = &mGraph;
delete graphPtr;

You could have the same effect with some kind of reference-counting smart pointer.