Question about using boost::shared_ptr in an std::list or vector

Started by
14 comments, last by Zahlman 16 years, 3 months ago
Mastadon, regarding returning dumb/smart pointers and using shared_ptr in a container:

You should think about object ownership. If a SceneNode is allowed exist without being in the _nodes collection (BTW don't use _variable in your code, leading underscores are reserved for system stuff), then you should use a list or vector of shared_ptrs, and allow access through shared_ptrs (or weak_ptr's, but that's another discussion).

However, if _nodes owns all SceneNodes (i.e. is respoinsible for creating/deleting them) then you might find it easier to use a boost pointer container. This approach more correctly models exclusive ownership and as a bonus is marginally faster as well.
if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight
Advertisement
Quote:Original post by ChaosEngine
Mastadon, regarding returning dumb/smart pointers and using shared_ptr in a container:

You should think about object ownership. If a SceneNode is allowed exist without being in the _nodes collection (BTW don't use _variable in your code, leading underscores are reserved for system stuff), then you should use a list or vector of shared_ptrs, and allow access through shared_ptrs (or weak_ptr's, but that's another discussion).

However, if _nodes owns all SceneNodes (i.e. is respoinsible for creating/deleting them) then you might find it easier to use a boost pointer container. This approach more correctly models exclusive ownership and as a bonus is marginally faster as well.


Well... A SceneNode really has no reason to exist if the SceneManager does not exist. I was using shared_ptr only for assuring that all nodes would eventually be deleted..

Using a boost::ptr_vector might be what I'm looking for. Would I just return standard pointers in my adding functions?
Quote:Original post by mastodon
Quote:Original post by ChaosEngine
Mastadon, regarding returning dumb/smart pointers and using shared_ptr in a container:

You should think about object ownership. If a SceneNode is allowed exist without being in the _nodes collection (BTW don't use _variable in your code, leading underscores are reserved for system stuff), then you should use a list or vector of shared_ptrs, and allow access through shared_ptrs (or weak_ptr's, but that's another discussion).

However, if _nodes owns all SceneNodes (i.e. is respoinsible for creating/deleting them) then you might find it easier to use a boost pointer container. This approach more correctly models exclusive ownership and as a bonus is marginally faster as well.


Well... A SceneNode really has no reason to exist if the SceneManager does not exist. I was using shared_ptr only for assuring that all nodes would eventually be deleted..

Using a boost::ptr_vector might be what I'm looking for. Would I just return standard pointers in my adding functions?
I've never used the Boost pointer containers, but my understanding is that they assume exclusive ownership of the passed-in pointers. If that is in fact the case, then I doubt you'd want to go passing the pointers around. (If that's what you had in mind, I'd just stick with shared_ptr.)
Quote:Original post by jyk
I've never used the Boost pointer containers, but my understanding is that they assume exclusive ownership of the passed-in pointers. If that is in fact the case, then I doubt you'd want to go passing the pointers around. (If that's what you had in mind, I'd just stick with shared_ptr.)


Depends on what you mean by "passing the pointers around". Of course, storing a copy of the exclusively owned pointer is not necessarily clever, but there's no reason you can't do something like:

for (boost::ptr_vector<SceneNode>::const_iterator iter = _nodes.begin();     iter != _nodes.end(); ++iter){    Render(*iter);}


or something similar.

OTOH, this
SceneNode* GetNode(int index){    boost::ptr_vector<SceneNode> nodes;    nodes.push_back(new SceneNode);    nodes.push_back(new SceneNode);    nodes.push_back(new SceneNode);    return nodes[index];}
is definitely not smart! [grin]
if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight
Quote:Original post by ChaosEngine
SceneNode* GetNode(int index){    boost::ptr_vector<SceneNode> nodes;    nodes.push_back(new SceneNode);    nodes.push_back(new SceneNode);    nodes.push_back(new SceneNode);    return nodes[index];}
is definitely not smart! [grin]
Yes, that's the sort of thing I had in mind :)

Actually though, I believe it would be 'return &nodes[index]', since in general the Boost pointer containers return references, not pointers (IINM).
Quote:Original post by jyk
I've never used the Boost pointer containers, but my understanding is that they assume exclusive ownership of the passed-in pointers.


That is my understanding also.

Quote:If that is in fact the case, then I doubt you'd want to go passing the pointers around. (If that's what you had in mind, I'd just stick with shared_ptr.)


Would you feel safer about passing around weak_ptrs constructed from the container contents? Or perhaps references? (After all, ptr_foo<T>::value_type is T rather than T*.)

As for the "dangerous temporary": jyk's code should be fine, but making the shared_ptr variable explicit (a) is definitely fine and (b) avoids making a .back() call for something we just inserted.

This topic is closed to new replies.

Advertisement