4

I am currently manually managing the lifecycle of objects in my project. I am considering switching to smart pointers, specifically tr1::shared_pointer and tr1::weak_ptr. However, I am seeing a couple of problems and would like to get some input on best practices.

Consider the following class diagram:

Polyhedron Class Diagram

In this diagram, the thick arrows represent associations with an ownership semantics (the source is responsible for deleting the target or targets). The thin arrows represent associations without ownership.

From what I understand, one way of implementing an association with ownership semantics would be to use tr1::shared_ptr (or a collection thereof). Other associations can be implemented using either tr1::shared_ptr or tr1::weak_ptr. The former is prohibited if it may result in circular references because that would prevent proper release of resources.

As you can see, there is a circle of associations between classes Edge and Side. I can easily break this by implementing the "left" and "right" associations from Edge to Side using tr1::weak_ptrs. However, I would prefer using the smart pointers to document, in code, the ownership semantics of the associations. So I would like to use shared_ptrs only for the associations represented by thick arrows in the diagram, and weak_ptrs for everything else.

Now my first question is: Should I use weak_ptrs liberally as described above, or should I use them as little as possible (only to avoid circular references)?

The next question is: Suppose I have a function that computes the average of a set of vertices. Suppose further that I have implemented the association from the Polyhedron to its Vertices like so: 

class Vertex;
class Polyhedron {
protected:
    std::vector<std::tr1::shared_ptr<Vertex> > m_vertices;
};

and that I have implemented the association from a Side to its Vertices like so:

class Vertex;
class Side {
protected:
    std::vector<std::tr1::weak_ptr<Vertex> > m_vertices;
};

Note that the set of vertices of a Side is a subset of the set of vertices of a Polyhedron. Now let's say I have a function that computes the average of a set of vertices. The function is currently declared like so:

const Vertex centerOfVertices(std::vector<Vertex*> vertices);

Now if I represent the associations as above, I suddenly need two functions if I understand everything correctly:

const Vertex centerOfVertices(std::vector<std::tr1::shared_ptr<Vertex> > vertices);
const Vertex centerOfVertices(std::vector<std::tr1::weak_ptr<Vertex> > vertices);

Because I cannot convert between a vector of shared_ptr and a vector of weak_ptr. This smells funny to me. I would like to know what approach I should take here to avoid such a situation.

Kristian Duske
  • 1,769
  • 9
  • 14
  • What do you mean "a `weak_ptr` can't be converted to a `shared_ptr`"? Call `lock()` on the `weak_ptr` and it gives you a `shared` – John Dibling Jun 13 '12 at 13:38
  • 2
    I think this would be abusing `shared_ptr`, I didn't read this carefully but it doesn't look like anything actually _shares_ ownership. Use `unique_ptr` and raw pointers instead, and make guarantees to systems you give (weak) raw pointers to that the object they point to will be valid during their scope. – David Jun 13 '12 at 13:43
  • I think I'd understand this a lot better if I knew what `side` represented. Does it mean 'face'? – Rook Jun 13 '12 at 13:44
  • @JohnDibling thanks for pointing that out, I wasn't aware. – Kristian Duske Jun 13 '12 at 13:45
  • Dave: none of the major entities there has a strict definition of 'owner' or 'parent'. Where polyhedra meet, they may share vertices, edges and vertices, or edges, vertices and faces. I assume that's what the OP wants to represent. – Rook Jun 13 '12 at 13:45
  • @Dave This is just a subset of the model, there can be shared ownership elsewhere in the model, but not everywhere, so unique_ptr is also important for me. – Kristian Duske Jun 13 '12 at 13:47
  • @Rook Yes, side means face, I had to call them sides because the name face is used elsewhere in the model and I can't change it. It's not an optimal name though. – Kristian Duske Jun 13 '12 at 13:49

3 Answers3

1

However, I would prefer using the smart pointers to document, in code, the ownership semantics of the associations.

As you should. That’s what they express perfectly, after all.

So I would like to use shared_ptrs only for the associations represented by thick arrows in the diagram, and weak_ptrs for everything else.

Go for it, with one caveat: your ownership doesn’t look at all like shared ownership, it’s simple, unique ownership. Consequently, the appropriate smart pointer here isn’t shared_ptr but rather std::unique_ptr, and the weak pointers would then simply be raw pointers.

Now if I represent the associations as above, I suddenly need two functions …

Yes. Well, or you use templates.

Alternatively, since the function isn’t actually interested in sharing ownership at all, you could pass raw pointers to it, but this would of course imply first getting raw pointers from your structure, which requires an added step for the client, which may not be good for the interface.

Konrad Rudolph
  • 530,221
  • 131
  • 937
  • 1,214
1

Using shared pointers seems sensible, especially as you may find that vertices etc. can be shared between polyhedra.

To convert from a vector of weak pointers to a vector of shared pointers, use an explicit constructor:

centerOfVertices(std::vector<std::tr1::shared_ptr<Vertex> >(vertices.begin(), vertices.end()));
ecatmur
  • 152,476
  • 27
  • 293
  • 366
0

You certainly can also use shared_ptr for cyclic references. There are some rare situations where this actually makes sense. However, you must take care to break the cycle once you are done with the objects.

gexicide
  • 38,535
  • 21
  • 92
  • 152