Re: boost::shared_ptr and multiple inheritance
On Jun 22, 8:23 am, EnsGabe <ensg...@gmail.com> wrote:
Suppose you have a class heirarchy as such:
class Base{
...
};
class Mid1 : public Base{
...
};
class Mid2 : public Base{
...
};
class Derived: public Mid1, Mid2{
};
Mid1, Mid2, and Base are ABC.
Are you sure that you want several instances of Base in the
final object? Or do you want virtual inheritance.
What is an effective way to manage the lifetime of this object?
In what way? How you manage lifetime of an object depends on
the semantics of the object.
Currently, I leak Derived (and anything similar to Derived)
all over the place by not reclaiming them at all.
You mean you never call delete on them. (If the objects don't
have a deterministic lifetime, requiring a explicit call to
delete, then garbage collection is the obvious answer.)
That works for now, in as much as when I am done with them I
am done with execution of my program, but is not a solution
that will work for the future.
My use at the moment is as such:
class ObjectHolder {
public:
...
void addMid1(Mid1 *p) { assert(p); mid1s.push_back(p); };
void addMid2(Mid2 *p) { assert(p); mid2s.push_back(p); };
private:
std::vector<Mid1*> mid1s;
std::vector<Mid2*> mid2s;
...
};
There will be many different classes that are equivalent to
Derived (in the sense that they are deriving from Mid1 and
Mid2.) There will also be classes that derive from one or the
other of Mid1 and Mid2. All of them will be registered
exactly once in mid1s and/or mid2s, whichever they are derived
from. References to the objects will not exist outside of
ObjectHolder. Objects may contain references to other
objects; the directed graph that they form will be acyclic.
In which case, reference counted pointers can be used as a
substitute for garbage collection. It's more invasive, and
usually somewhat slower, but installing boost::shared_ptr is a
lot easier than installing the Boehm collector.
My first instinct was to delete every element of mid1s and
mid2s in the destructor for ObjectHolder, but that will not
work when a Derived has been inserted into both vectors. My
next idea was to use boost::shared_ptr and use that to
automatically manage the lifetime of the object, but there was
nothing in the documentation that I saw that led me to believe
that one could use a shared_ptr across a class heirarchy.
You can, provided that all of the instances of shared_ptr derive
from the same initial shared_ptr. (What you can't do is create
an initial shared_ptr twice from a raw pointer. Basically,
you should probably create the initial shared_ptr as a
shared_ptr< Derived >, at the site of the new, and use nothing
but shared_ptr after that---shared_ptr supports all of the usual
pointer conversions, or it should.)
Since the 'this' pointer for an object is different
depending on the type it is being used as, I'm (possibly erroneously)
assuming that a shared_ptr will mismanage the reference count for the
pointer since they are using different pointers. Am I wrong in my
understanding of the semantics of boost::shared_ptr?
Sort of. Globally, there are two large families of reference
counted pointers: invasive and non-invasive. Since you're
dealing with a known hierarchy, you can easily use either. The
invasive pointers have the advantage that you can create new
smart pointers from the raw pointer anywhere you want; you
could, for example, have the only smart pointers in the two
containers, and that would work. On the other hand, when
multiple inheritance is involved, the base class (which derived
from the RefCntObj, or whatever) *must* be virtual, period.
Non-invasive pointers have the advantage that the pointed to
object doesn't need to be aware that reference counted pointers
are being used---you can even create a shared_ptr<int> (not that
there would ever be any reason to). On the other hand, every
time you create an instance of the smart pointer from a raw
pointer, you get a new counter.
Which is more appropriate in your case depends on the way the
objects are allocated and who manages the containers.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34