Re: workaround for auto_ptr<> in STL containers?
On 24 d=E9c, 11:09, Christof Warlich <cwarl...@gmx.de> wrote:
Michael Doubez wrote:
In the example, I used pointer semantic to exploit polymorphism, which
is fine for this simple case, but tracking deletion of objects quickly
becomes difficult in more complex scenarios.
In which scenario. Your code doesn't expose how you un-register them.
Registration is a one-time activity that only happens once for each new
Shape class that is added to the framework. This is why the Template
instances are static. Thus, unregistration is not necessary. Its only
reason is to have a template of each Shape object to clone from.
But is a shape inherit from another (which is not the case in general
I assume, all the most if constructors are private), this means the
object will be registered twice. In the un-registration performs
destruction, you would have interesting problems ;)
From a design point of view, in this case, I would have make a class
that performs the registration such that the mechanism would be
externalized:
class ShapeRegistrer
{
ShapeRegistrer(Shape* shape, bool own_shape){
// register shape
}
~ShapeRegistrer()
{
if(own_shape) delete shape;
}
};
And you could implement the semantic you want.
Registration is not even performed in all constructor.
You probably misunderstood the example code: [snip]. But as I said,
it may be rather complex when a complex container structure is needed.
I see: you wanted a prototype based system with automatic
registration.
[snip]
IMO there is a design issue here rather than a technical one.
I don't think so, my (real) code works fine, including object deletion.
I just thought object deletion could have been made a bit more generic.
And using BOOST shared_ptr<> or implementing reference counting are both
viable solutions.
I don't see how deletion could be made generic since you don't tell us
how you determine the lifetime of the object.
shared_ptr<> has the advantage that you don't have to specify it but I
thought you had a compiler version issue with boost.
--
Michael