Re: which pointer
On Jan 4, 12:09 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
On 13 Dec 2009, 10:56, James Kanze <james.ka...@gmail.com> wrote:
but the aim was to allocate a Call and store it in
CallList. If CallList throws the smart_ptr will destroy
the Call, otherwise process the message and the call
remains in the CallList for more message processing.
smart_ptr would not allow copy or assignment.
Which smart_ptr?
that was the question (actually the title of the post). I was
asking which smart ptr I should be using. Is there a standard
one that does what I want I do I need to write one?
To answer that, I'd have to know exactly what you want to do.
What is the lifetime of the pointed to object? Does it have
identity? Must it be polymorphic?
(I am supposing that "smart_ptr", here, is a
generic name for a set of smart pointers, e.g. std::auto_ptr,
boost::scoped_ptr, boost::shared_ptr, etc. If not: I have no
idea what the class does.) Some do, some don't.
Release returns the pointer value and zeros its record. I
was going to call it ExplicitReleasePointer. But then I
thought,surely boost have already done this. Aha!
scoped_ptr! Oops no. No release(). The rationale for this
is that scoped_ptr implies no transfer of ownership. But I
want to transfer ownership. That I should use auto_ptr if
I want transfer of ownership semantics. But how do I
coerce auto_ptr into doing the cleanup. Should I be making
my container class do the cleanup? Or should I be using
shared_ptr in both the container class and my calling
function?
I'm not sure what you mean by "cleanup",
well, generally call the dtor
or when it should occur. One common idiom is to use
auto_ptr until the newly created object has registered
itself somewhere, so that it can be found by future events.
Generally, in such cases, one of those future events will
trigger the destruction of the object ("delete this"), and
the destructor will do all necessary clean-up (including
deregistering the object).
this sounds exactly what I want.
It's a frequent idiom for objects that can handle events (and
for which one of the events triggers destruction). In such
cases, there are two possible solutions: the constructor of the
object enregisters the object with the event handler, and you
might not even need to maintain a pointer to it (outside of the
event handler) at all---I've more than a couple of cases where
I've written "new SomeType" without assigning the results of the
new to any pointer whatsoever. If for some reason, this isn't
possible, the best solution is generally to save the results of
new in an auto_ptr until the object has been correctly enrolled,
and then call release on the auto_ptr.
[...]
Just to be clear, by "container class", you really mean some
sort of registry.
if that's the appropriate terminology. It contains calls...
That's not really sufficient. What I mean is that the container
is somehow used to find the object, say when an external event
arrives.
The allocated object can't be contained; at
best, a copy of it can be contained,
or a pointer
But the semantics of containing a pointer and containing an
object are radically different. Which semantics do you want?
but if the object supports copy, you probably don't want
dynamic allocation to begin with.
I can't know in advance how many calls there will be.
But if the object supports copy, it doesn't matter.
Does the object have an identity, or no?
I suppose the logic is that ownership is shared so you need a
shared pointer.
I sort of doubt that. If the object is registering itself in
some sort of registry, the logic is more likely no ownership.
It's an entity object, capable of taking care of itself.
?
self deleteing?
Yes. If the object reacts to events, one of those events could
very easily result in a demand that the object cease to exist.
In my own code, I'd guess that well over half of the calls to
delete are "delete this".
--
James Kanze