|
Boost : |
From: Martin Schulz (Martin.Schulz_at_[hidden])
Date: 2007-09-19 08:22:59
> 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_at_[hidden]) 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk