Re: workaround for auto_ptr<> in STL containers?
On Dec 28, 9:35 am, Michael Doubez <michael.dou...@free.fr> wrote:
On 25 d=E9c, 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=E9c, 20:07, Christof Warlich <cwarl...@gmx.de> wrote:
[...]
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.
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.
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