Re: naked pointer vs boost::shared_ptr<T>
Ulrich Eckhardt wrote:
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.
And that RAII doesn't really apply. RAII is used to associate
the life of a dynamically allocated resource to the life of some
other object (typically, and most usefully, an object with
automatic lifetime). In this case, there is no other object
which has the right lifetime.
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,
It's more than just memory; it's the object, as an object. (If
memory is the only problem, the Boehm collector handles that
just nicely.)
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.
I presume that when you say "reference the memory via the
object", you mean "reference the memory as if it were a valid
instance of the object". And I agree, dangling pointers should
be avoided.
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).
Doesn't help. The object ceases to exist as a valid object
because of an external event, whether you hold pointers to it or
not, and whether the destructor has been called or not. One of
the reactions to that external event must be to notify all other
objects which hold pointers to the object, so that they know to
not use the pointer. (Typically, they will null it, if it is a
single pointer, and remove it completely from the container if
it is in a container.) If you're not doing this, nothing works,
regardless of the type of pointer you use. And if you're doing
it, there's absolutely no point in using any sort of fancy
pointer; raw pointers work just as well.
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.
That is, in fact, the only solution which works. Except that if
the pointer is in a container, for example, you don't want to
just set it to null; you want to remove it from the container.
And of course, whoever was counting on the object might have
other things to do as well. (Thus, for example, in a telecoms
application, loosing a PCB means notifying all of the
connections which use that PCB; the connections don't just null
the pointer to the implementing PCB, they activate the back-up
connection is one exists, change state, etc.)
Now, considering smart pointers, those just help modelling the above.
Many places where I've worked have tried to find a generic
solution to the second, above. It's usually called relationship
management, not smart pointers, of course, and to date, I've yet
to see anything general that works.
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.
In which case, you might as well use the Boehm collector, and be
done with it. It works even better.
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.
But it won't remove the weak_ptr's from containers, nor cause
the objects using them to change state, activate back-ups or
what have you. It only does a very small part of the job, and
anything which does the rest also handles this part.
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.
Generally, in such a system, mutex's have to be held at the
transaction level. Precisely for this reason. (Independantly
of whether an object is waiting on the mutex, you can't allow
another object to obtain a pointer to your object without
creating the necessary observer, so that it can be notified when
you die. Otherwise, you inevitably do get dangling pointers.)
[...]
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.
Exactly. It doesn't remove itself from the container which
contained it. You leak.
For that matter: most of the time, my collection is and
std::set< T* >. Can you even use weak_ptr's in a set? What
happens to the ordering if one nulls itself?
Shared_ptr do have uses (especially if for some reason you
cannot use the Boehm collector), but those uses only affect a
small percentage of the total objects. As I have already said,
most of the time, value objects shouldn't be dynamically
allocated to begin with, and true entity objects have an
explicit lifetime dependant on their semantics, and thus require
explicit management. And such objects generally represent well
over 90% of the objects in an application.
I tried systematically using boost::shared_ptr in an
application, and backed out. In the end (in this particular
application), the only place where it was really relevant had a
cycle, which had to be managed explicitly to ensure the correct
order of deletion. In other applications, there will be some
uses for it, but...
The orginal question was: "Should we stop using naked pointer
and replace all of them with boost:shared_ptr or
(shared_array<T> or scoped_ptr)?" And the answer to that is
simply NO. The poster is looking for a silver bullet, and there
isn't one. You have to think about object lifetime, regardless.
It's a design issue, which must be addressed at the design
level. And once you've addressed it at that level, you'll find
that different types of pointers are appropriate in different
cases, and that raw pointers are appropriate in a surprising
number of cases, probably more that shared_ptr or scoped_ptr.
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.
Which is, in some ways, a problem, because the semantics (what
you are telling the reader) aren't really the whole truth.
There are cases where they are, and in such cases, it is quite
appropriate to use such pointers---although I can't quite come
up with a scenario where boost::weak_ptr would be appropriate.
But any time the semantics are that the object has its own,
explicit lifetime (logically, at least), then using shared_ptr
or something similar is lying to the reader; it tells him
something about the object that isn't true.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]