workaround for auto_ptr<> in STL containers?
Christof Warlich
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.:
#include <iostream>
#include <typeinfo>
#include <vector>
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;
};
Rectangle Rectangle::Template;
int main() {
int number;
long address;
while(std::cin.good()) {
std::cout << "Enter number to create a shape:\n";
for(unsigned int i = 0; i < Shape::Templates.size(); i++) {
std::cout << i << ": " <<
typeid(*(Shape::Templates[i])).name() << std::endl;
}
std::cin >> std::dec >> number;
Shape::Templates[number]->Clone();
}
}
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. 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.
Any ideas how this (i.e. auto-deletion of unreferenced objects) could be
handled in a generic way while using STL containers?
Thanks for any suggestions,
Christof
Branimir Maksimovic
> 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. 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.
>
> Any ideas how this (i.e. auto-deletion of unreferenced objects) could be
> handled in a generic way while using STL containers?
>
> Thanks for any suggestions,
>
> Christof
base class?
http://www.boost.org/doc/libs/1_35_0/boost/shared_ptr.hpp
Greets
Christof Warlich
>> Any ideas how this (i.e. auto-deletion of unreferenced objects) could
>> be handled in a generic way while using STL containers?
>>
> base class?
> http://www.boost.org/doc/libs/1_35_0/boost/shared_ptr.hpp
Yes, I new BOOST smart pointers do work fine with STL containers, but as
I'm bound to a really ancient compiler (gcc2.95) in an embedded project,
I fear encountering difficulties with Boost libraries.
Anyhow, implementing a light-weight reference counting myself might be
an alternative.
Thanks and regards,
Christof
Michael Doubez
> Hi,
>
> 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.:
>
> 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.
> 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.
>
> 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.
IMO there is a design issue here rather than a technical one.
--
Michael
Christof Warlich
>> 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.
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.
> Registration is not even performed in all constructor.
You probably misunderstood the example code: The parameter-less
constructors are only supposed to be called once for each static
Template instance. Normal object creation is done through the Clone()
member, which uses the other constructor. Maybe I should have made the
constructors private to point this out. What you are probably referring
to by un-register is object deletion. I left this out here deliberately
as it is fairly easy in such a simple case anyway and would have only
blown up the example as it needs some container to keep track of the
existing shape objects. But as I said, it may be rather complex when a
complex container structure is needed.
>
>> 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.
>>
>> 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.
No they can't. Look at the code, the objects are created though Clone(),
which uses new. Again, hit me for not having made the constructors private.
>
> 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.
James Kanze
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
Michael Doubez
> 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
Michael Doubez
Yes.
The underlying question was "how do you know that auto_ptr<> would
have been a alternative ?"
If a container of auto_ptr<> (such has a list<> rather than a
vector<>) had been an alternative, it only means the lifetime of the
object would have been tied to the lifetime of the container (or its
presence in the container). If that's the case, I don't see from where
the "complex case" come from.
[snip]
--
Michael
James Kanze
> On 25 déc, 13:40, James Kanze <james.ka...@gmail.com> wrote:
> > On Dec 24, 8:34 am, Michael Doubez <michael.dou...@free.fr> wrote:
> > > On 23 déc, 20:07, Christof Warlich <cwarl...@gmx.de> wrote:
[...]
I'm beginning to loose a little bit of context here. But off
hand: a (standard) container doesn't own objects it points to;
that's not part of its semantics. In a GUI, it is a reasonable
design for the containing element (panel, etc.) to own the
elements it contains, however, and using a standard container of
boost::shared_ptr is one way of achieving this. A bit
misleading, possibly, since "shared_ptr" suggests shared
ownership, but not to a point that a simple comment couldn't
correct the impression. It does result in a somewhat strange
idiom for shared_ptr, in that you don't allow shared_ptr to
escape the containing element (calling get() and returing a raw
pointer if you want to return a pointer to a contained element),
but technically, it works: the semantics of containment pretty
much guarantee the absence of cycles, for example.
--
James Kanze