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
Well, the name heap makes me think of a certain kind of memory management system. Probably a name like Keepalive_bucket would be clearer?
Heaps should be non-copyable, vectors aren't.
Ok, that is a design choice and clearly influences the semantic.
5. Raw pointers can be handled more efficiently than shared_ptrs
But think of it - if that pointed-to object is in use by some other means, it would be destroyed by the heap destructor nevertheless. Using shared pointers, the pointed-to objects are kept alive as long as either the heap lives or as long they are used, whatever is longer.
6. Better syntax. Repeating a long type name twice as with boost shared_ptr can be tedious
Yes, I already noted that.
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?
If ist helpfull to you, then go ahead and use & improve it. An (untested) wrapper class I would start with would be something like: class Keepalive: private boost::noncopyable { Std::vector< boost::shared_ptr<void> > v; public: template <typename T> void put(boost::shared_ptr<T> p) { v.push_back(p); }; template <typename T> void put(std::auto_ptr<T>& p) { v.push_back(boost::shared_ptr<T>(p)); }; template <typename T> void put(T *p) { v.push_back(boost::shared_ptr<T>(p)); }; }; Does that solve your needs? -- Dr. Martin Schulz (schulz@synopsys.com) Software Engineer Synopsys GmbH Karl-Hammerschmidt-Str. 34 D-85609 Dornach, Germany Munich office: +49 (89) 993-20203 Home office: +49 (721) 6099511 http://www.synopsys.com