Question

I have an abstract class Reticule defined like so:

class Reticule : public Drawable, public Object {
    //some irrelevant methods to the question
};

It is used for drawing targeting reticules, i.e. if I wanted a spell to have a circle or a conal AoE reticule, I would derive from the above class e.g:

class Circle : public Reticule {
public:
    Circle(float radius);

    //etc
};

I have another class World with 2 methods, one for registering something that is drawable and another that registers objects.

class World {
public:
    void registerDrawable(Drawable* drawable);
    void registerObject(Object* object);

    //other irrelevant methods

private:
    std::list<Drawable*> drawables_;
    std::list<Object*> objects_;
};

These functions add the pointers to the associated containers. This allows objects in the world to interact with one another.

In my spell I am creating the reticule like so:

reticule_ = std::unique_ptr<Recitule>(new Circle(3.0f));

My problem is that, how am I meant to register the reticule to my World class. It works to do this:

world.registerDrawable(&(*reticule_));
world.registerObject(&(*reticule_)));

but that doesn’t seem right to me as I defined reticule_ as a unique pointer and I now have 2 more pointers pointing to it, they’re just not of type Reticule*

Should I not use an unique_ptr? Do I change everything to shared_ptr but then that doesn’t make sense when adding a simple object to the world.

Answer 1

You can’t use unique_ptr if you want them both to “own” it. In that case shared_ptr is appropriate.

Alternatively you could register the raw pointer. You would need to be sure to unregister the object before it was destroyed however. This creates other problems, because throwing within a destructor is a bad thing.

Using shared_ptr on simple objects is fine though, and it would be my recommendation unless the profiler tells you that it is a problem.