Re: [boost] RFC - lifetime management

From: Johan Torp (johan.torp_at_[hidden])
Date: 2007-09-18 17:48:39

Martin Schulz-3 wrote:
> 
> To me, that sounds very much like a std::vector<boost:shared_ptr<void>
> [snip]
> Does this do what you intended? 
> 
> With a bit of syntactic sugar, it would be possible to avoid the
> intermediate shared_ptr type, probably. I consider all real work already
> done. 
> 
> Is that what you thought about?
> 

Yes that's basically it! I often create std::vector<boost::any> containing
boost:shared_ptrs. Using std::vector<boost::shared_ptr<void> > is clearer
and lessens the need for this utility class a bit. 

Still, the heap class is even more clear, easier to use and easier to reason
about. 
I see the following benefits over std::vector<boost::shared_ptr<void> >:

  1. More informative class and method names

  2. You can't access anything put in the heap through the heap. This makes
code analysis a lot easier.
      For instance, using heap.put(new Foo) you are sure noone can access
the Foo instance at all.

  3. There is no way to delete something in a heap or clear it so you are
sure what's put will remain alive
      as long as the heap. (I no longer believe premature deletion is good
idea). 
      Heaps should be non-copyable, vectors aren't.

  4. Because of 2 & 3 suitable classes (such as display list nodes) can
expose a get_heap-method
      without risking the class's clients affecting each other or the
instance.

  5. Raw pointers can be handled more efficiently than shared_ptrs

  6. Better syntax. Repeating a long type name twice as with boost
shared_ptr can be tedious

Still I'm not sure if these points are enough to motivate a new utility
class. It's not exactly a killer app, even though I find it very useful in
MVC architectures (linking controllers life time to views) and classes with
lots of RAII members. What do you think?

Thanks for your input! /Johan

-- 
View this message in context: http://www.nabble.com/RFC---lifetime-management-tf4425074.html#a12766798
Sent from the Boost - Dev mailing list archive at Nabble.com.