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.