Re: naked pointer vs boost::shared_ptr<T>
James Kanze wrote:
Dejan.Mircevski@gmail.com wrote:
On Mar 2, 6:31 am, "James Kanze" <james.ka...@gmail.com> wrote:
On Mar 2, 4:33 am, "Dejan.Mircev...@gmail.com"
<Dejan.Mircev...@gmail.com> wrote:
On Mar 1, 5:10 am, "James Kanze" <james.ka...@gmail.com> wrote:
In my own applications, I find that most pointers are to objects
with explicit lifetimes, and I've yet to find a smart pointer
which is applicable to them (although I've tried).
Isn't any smart pointer with a reset() method applicable? The memory
owner can declare a smart instead of a naked pointer, and call
reset()
instead of delete. Everything else would remain the same. The
advantage would be exception safety and a clear convention for who
owns the memory at any given time.
But what does that buy you over a raw pointer?
The usual RAII goodness: sneaky control-flow scenarios can't rob you
of a chance to call delete, compiler-generated destructors and copy
constructors do the right thing, etc.
You missed the point. RAII doesn't work in this case, at least
not in its general meaning. The destruction of the object is
triggered by an explicit, external event, and not the fact that
you leave scope.
I'd agree that there is some external event happening that has some
implications. So much is dictated by the circumstances. What is not
dictated is how that is modeled in C++, that is rather a question of
choice.
With smart pointers there's also an explicit and standard convention
for who owns the memory, which I find more readable than the
implicit conventions necessary with raw pointers.
In this case, the object itself owns the memory. This is, after
all, the classical OO idiom, and the object has identity and
behavior. It doesn't make sense for anyone else to own the
memory.
How about replacing the verb "own" with "reference"? It may be that the
object itself owns its memory, but other parts of the program might still
reference the memory via the object. Now, there are several ways to model
that, but I'll assume that one thing must not happen: dangling
references/pointers. The reason is that C++ doesn't provide any means to
detect such an invalid reference (i.e. it's UB) and they typically present
hard to detect errors when they happen.
I see two ways to achieve this goal:
1. The object doesn't get destroyed until the last reference to it is gone.
This is what is easiest modeled with shared ownership using reference
counting or garbage collection. Note that this is only about the C++
object. The application logic might mandate via external that the object is
destroyed, but as far as C++ is concerned the object still exists,
typically as a defunct shell (e.g. when unplugging a thumbdrive).
2. Before destroying, all references to the object are reset to a detectable
state (e.g. null pointer). This requires knowledge of every reference to
the object.
Now, considering smart pointers, those just help modelling the above. For
the first case, you simply use a refcounting pointer like boost::shared_ptr
or boost::intrusive_ptr. The external event then simply transitions the
object to a defunct state.
For the second case, you can use a single boost::shared_ptr inside the
object itself (yes, this doesn't give you scoped access or RAII) and
externally only store boost::weak_ptrs. If the external triggers the
disappearance of the object, it will only reset its shared_ptr to itself
which will first invalidate all the weak_ptrs still referencing the object
and then finally delete the C++ object.
All this even works pretty well in a multithreaded program, but then there
is one thing to consider: several threads might make a call to the object's
members at once, so probably it will have some kind of mutex. Now, this is
a real case of shared ownership, because you can't destroy the mutex while
some other object is waiting for it. Therefore, it is often desirable to
use the approach that leaves a defunct shell of the objects.
Note too that if you use
the registry.erase() method, the object might not be destructed
immediately; someone might still be using it somewhere, and hold
a shared_ptr to it as well.
If someone else does hold a shared_ptr, that's a signal that the
object mustn't be destroyed yet.
No. That's a signal that there is an error in your software,
which must be corrected.
In your scenario, I'd have that
someone hold a weak_ptr, signaling that they don't mind the memory
getting deleted on them.
Except that afterwards, whoever is holding the weak_ptr has to
delete it, or you leak memory. Generally, if other objects
which hold pointers (which can navigate directly to the object)
must be notified, using some variant of the observer pattern, so
that they can remove the pointer.
Sorry, but I think you don't understand weak_ptr. In fact it is an
implementation of this observer pattern, i.e. it automatically becomes a
null pointer once the last shared_ptr to the object is reset. Yes, if you
need additional information than "has vanished" it isn't enough, also if
you need to handle the information right now instead of checking the
pointer on next occasion, but it still is good enough for many cases. Also,
and that is one big advantage IMHO, it has semantics defined by the types,
i.e. there is some meaning associated with shared_ptr and weak_ptr which
isn't the case with a raw pointer.
Uli
--
Sator Laser GmbH
Gesch??ftsf??hrer: Ronald Boers Steuernummer: 02/858/00757
Amtsgericht Hamburg HR B62 932 USt-Id.Nr.: DE183047360
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]