To use or not to use smart pointers?

[Boris]

[...]What I don't like about using smart pointers systematically (as
opposed to using them as a solution to a specific problem in
specific cases) is that they force an object lifetime model on
you, which in most cases is not the right one. As I said
earlier, most pointers are for navigation. You do NOT,

That makes perfectly sense to me as you can clearly distinguish two
concepts: Thanks to smart pointers raw pointers are used to indicate that
they don't own memory. However I typically use then references (which
doesn't work of course if you need to change the pointer somehow).

[...]I don't know how COM handles this, but the normal convention is
that if you receive a raw pointer, you don't have to worry about
lifetime. Too much. If you have a pointer to an entity object

There is no real solution in the COM world except looking up the MSDN
documentation all the time (or you can say .NET is the solution to this
and other problems in the COM world).

[...]

[...]And my experience is that automatically using just about any
tool results in misuse, and poor code quality. Most pointers in
my code are raw pointers, simply because most pointers are used
for navigation, in one way or another. Most "objects" are local

How do you make sure though that your pointers are not in fact
dangling pointers? Is it something the Boehm collector takes
care of?

Not directly. It does ensures that the memory won't be reused
for anything else as long as you have a pointer to it, so it's
possible to add a flag to the memory, which you assert each time
you use the pointer. But in general, you still need to use the
observer pattern, and notify all clients of the object anytime
the object ceases to exist.

I see. I don't think though that using the observer pattern makes more
sense than using smart pointers. Not only need all classes to support the
observer pattern for memory management. You have also a more tight
coupling than with smart pointers as A does not only own B anymore but
must register with B. I feel like however arguing with the wrong person as
I appreciate ideas like using garbage collectors in C++ to make memory
management easier. Developers refusing to use smart pointers because of
performance concerns might be however even less willing to use gargabe
collectors.

Boris

 

[JohnQ]

[major snip]

Can someone sum up (I'm not asking for an end to it) this thread? Because I
think it may have some (but I don't see what all the hullabalu could
possibly be about) value (because of all the posts and the topic) but I'm
too lazy to read and grok it all from the beginning. Or can someone at least
sum up the major points? (Just a thought. And thanks if you do.)

John
(Feel free to download the parser on my website that will help you decipher
what I type without having to endure parenthetical expressions).

 

[James Kanze]

[...]

[...]And my experience is that automatically using just about any
tool results in misuse, and poor code quality. Most pointers in
my code are raw pointers, simply because most pointers are used
for navigation, in one way or another. Most "objects" are local
How do you make sure though that your pointers are not in fact
dangling pointers? Is it something the Boehm collector takes
care of?

Not directly. It does ensures that the memory won't be reused
for anything else as long as you have a pointer to it, so it's
possible to add a flag to the memory, which you assert each time
you use the pointer. But in general, you still need to use the
observer pattern, and notify all clients of the object anytime
the object ceases to exist.

I see. I don't think though that using the observer pattern makes more
sense than using smart pointers.

If smart pointers could take care of it, it doesn't. Typically,
however, the class having the pointer needs to react in some
way: remove the actual pointer from a container, or often, find
an alternative resource, or pass into a degraded functional
mode, or something along those lines. The problem is that the
reaction is too application specific to be easily handled by a
smart pointer. (Or is it? I've not given it a try, but I can
sort of imagine a smart pointer which understands something
about the container which contains it, and removes itself when
notified that the pointed to object has ceased to exist.)

Not only need all classes to support the
observer pattern for memory management. You have also a more tight
coupling than with smart pointers as A does not only own B anymore but
must register with B.

Again, if a smart pointer actually fits the bill, so much the
better. My experience has been that they rarely do.

I feel like however arguing with the wrong person as
I appreciate ideas like using garbage collectors in C++ to make memory
management easier. Developers refusing to use smart pointers because of
performance concerns might be however even less willing to use gargabe
collectors.

Probably. For many applications, garbage collection will
actually be faster than either smart pointers or manual memory
management. But people who reject the smart pointer solution
out of hand for imagined performance issues will doubtlessly do
the same for garbage collection. (It's interesting to note that
in the presence of polymorphism, at least as it is typically
implemented in C++, a dangling pointer can result in the same
type of security hole as a buffer overflow. Garbage collection,
of course, eliminates this. It doesn't make an incorrect
program correct, but it does limit the dammage that can be done
because of the error.)

 

[Kai-Uwe Bux]

[...]
[...]And my experience is that automatically using just about any
tool results in misuse, and poor code quality. Most pointers in
my code are raw pointers, simply because most pointers are used
for navigation, in one way or another. Most "objects" are local
How do you make sure though that your pointers are not in fact
dangling pointers? Is it something the Boehm collector takes
care of?
Not directly. It does ensures that the memory won't be reused
for anything else as long as you have a pointer to it, so it's
possible to add a flag to the memory, which you assert each time
you use the pointer. But in general, you still need to use the
observer pattern, and notify all clients of the object anytime
the object ceases to exist.

I see. I don't think though that using the observer pattern makes more
sense than using smart pointers.

If smart pointers could take care of it, it doesn't. Typically,
however, the class having the pointer needs to react in some
way: remove the actual pointer from a container, or often, find
an alternative resource, or pass into a degraded functional
mode, or something along those lines. The problem is that the
reaction is too application specific to be easily handled by a
smart pointer. (Or is it? I've not given it a try, but I can
sort of imagine a smart pointer which understands something
about the container which contains it, and removes itself when
notified that the pointed to object has ceased to exist.)

What you can have is the observer pattern packaged within the smart pointer.
The pointer would have a method where you can register a function object to
be called when the pointee is about to be deleted through any other pointer
pointing to it. Each pointer will have its own call back object even though
the pointees are shared. You could even associate two chains of call backs
with the pointee: one list for actions to be done immediately before
destruction of the pointee and the other list for actions to be done right
after.

Implementation ideas: instead of a reference count maintain a list doubly
linked list of smart pointers (all pointing to a given pointee). Copy
construction appends to the list, destruction removes from the list. As
soon as the list goes empty (i.e., reference count == 0), you delete the
pointee. Also, you have a method for freeing that runs through the list and
calls the registered call back objects (tr1::function comes to mind). It
should also set the pointer to 0 so that future attempts to dereference
trigger an assert in the operator* or operator-> method.

The call back could either be registered upon creation of the smart pointer
object or through a member function template register().


Best

Kai-Uwe Bux