Re: inheritance headache....
On Feb 1, 4:14 pm, "b...@blah.com" <GrahamJWa...@gmail.com> wrote:
On Feb 1, 1:36 pm, James Kanze <james.ka...@gmail.com> wrote:
On Jan 31, 11:12 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* b...@blah.com:
class abstractDescription
{
AbstractTarget* create(AbstractDescription* desc)
{
desc->create();
}
}
It's clear what you mean, something like
struct AbstractDescription
{
virtual std::auto_ptr<AbstractTarget> create() const = 0;
};
How is it so clear? Normally, auto_ptr suggests that the
caller will be responsible for deleting the object. And
most of the time I've seen such a pattern used, this simply
isn't the case---the object registers itself in its
constructor for some sort of external events, and deletes
itself when the appropriate event arises.
this definitely has grabbed my attention as a potentially more elegant
solution. Does anybody have any docs/examples of this in action... I
would be delighted to read more. I was already thinking about this in
parallel... though am missing the details. At this stage I am very
much interested in the most elegant solution....performance is not an
issue (if that can ever be said when writing "elegant" code).
Which is the elegant solution, what Alf suggested, or what I
suggested? Or perhaps better stated, what is the role of the
class in the application: my solution is generally applicable to
entity classes, but I use Alf's (or something similar, with my
own reference counted pointers) when I'm dealing with agents in
legacy applications (where I can't use the Boehm collector).
Anyway, my solution very much depends on how you manage the
objects in general. One typical case (at least in the type of
servers I work on) is where the objects are addresses from the
outside via some external name (DN or other); the constructor
registers the object in a map (std::map< DN, AbstractTarget* >)
so that the request handler can find it. Delete requests (like
all other requests) are forwarded to the object, which does a
delete this. The destructor removes the object from from the
map.
In another frequent idiom, the object will first be passed to a
transaction manager, which is responsible for deleting it until
the commit phase of the transaction, at which time it is
enrolled in the final registry.
In other cases, the object will register itself with an event
hander for some sort of external events; certain events will
tell the object that it is no longer needed, in which case, it
will delete itself (also deenrolling in the destructor).
In my experience, such scenarios represent the majority of
polymorphic objects.
--
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