Re: workaround for auto_ptr<> in STL containers?
On Dec 24, 8:34 am, Michael Doubez <michael.dou...@free.fr> wrote:
On 23 d=E9c, 20:07, Christof Warlich <cwarl...@gmx.de> wrote:
I'm stuck in a rather standard situation that may therefore
be best illustrated with a standard example, i.e. a graphics
library offering a bunch of shapes.
I want to allow the user to create shapes at _runtime_ as
desired, so all my shapes are derived from an abstract Shape
class, allowing me to both keep track of all the created
shape objects in a list and to clone new shape objects from
the available shapes depending on user input, e.g.:
[snip]
struct Shape {
virtual ~Shape() {}
virtual Shape *Clone() = 0;
void Register() {Templates.push_back(this);}
static std::vector<Shape *> Templates;};
std::vector<Shape *> Shape::Templates;
struct Circle: Shape {
Circle() {Register();}
Circle(int radius) {std::cout << "Creating circle.\n";}
Circle *Clone() {
std::cout << "radius? " << std::flush;
int radius;
std::cin >> radius;
return new Circle(radius);
}
static Circle Template;};
Circle Circle::Template;
struct Rectangle: Shape {
Rectangle() {Register();}
Rectangle(int height, int width) {std::cout << "Creating
rectangle.\n";}
Rectangle *Clone() {
std::cout << "height, width? " << std::flush;
int height, width;
std::cin >> height >> width;
return new Rectangle(height, width);
}
static Rectangle Template;
};
[snip]
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 not even performed in all
constructor.
That, of course, is the question. In the case of a lot of GUI
objects, lifetime is in some way related to the display.
Destruction should occur when the containing display object is
disposed of, and ceases to become displayable. It's a design
issue (since destruction could in some cases result in concrete
actions occuring; the object deregistering itself for mouse
events, for example).
Whether this is "difficult" is a matter open to discussion, but
it's an aspect that has to be addressed, at the design level.
(I see a containment hierarchy -- containment being used here in
its everyday sense, and not the OO sense. And I can't see where
the difficulty would come from.)
Thus, I considered using std::auto_ptr<> to overcome this,
but auto_ptr<> does not seem to be compatible with STL
containers, where I want to keep my shapes in some sort of
list.
auto_ptr also doesn't have the required semantics.
Any ideas how this (i.e. auto-deletion of unreferenced
objects) could be handled in a generic way while using STL
containers?
How do you known you should auto-delete them ? They could be
on the stack.
That's a question of the class' semantics. I think it
reasonable to forbid GUI types from being on the stack.
IMO there is a design issue here rather than a technical one.
For starters, at least. Beyond that, I think that once the
design issues have been solved, the technical problems won't be
that difficult.
--
James Kanze