Re: To use or not to use smart pointers?
On Jul 21, 4:04 am, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
James Kanze wrote:
On Jul 18, 11:02 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
[...]
(and also should carry the burden of proving the correctness
for the code base resulting from a design decision in favor of
raw pointers).
That is, of course, the key part. Systematic use of shared_ptr,
where not appropriate, makes it very difficult to prove that the
code is correct.
Pointers in C++ are heavily overloaded. They offer two main
features at once, namely (a) decoupling life-time from scope
and (b) support for polymorphism.
I'm not sure that "overloaded" is quite the right word, but
there's more than a little truth in what you say. Pointers are
an implementation technique (like most language features), and
can be used to implement a number of different concepts. Three
important concepts are navigation, arbitrary lifetime and
polymorphism. And that smart pointers (at least the classical
smart pointers) are neither necessary, or even helpful, for the
first two. Before using a smart pointer, you should understand
why you're using a pointer to begin with.
The one case where I do (or did, before I started using the
Boehm collector) religiously use some form of reference counted
pointer was when I allocated dynamically only for reasons of
polymorphism; when without the constraint of polymorphism, I
would have used a value object, directly on the stack (and
copied when necessary). Such objects are far from the majority
in my code, however.
If you want the later, you are inviting upon you the perils
of the former.
Agreed. Technically, the problem isn't the pointer, but dynamic
allocation and the fact that you cannot copy without slicing.
But the result is that you end up using pointers, and needing to
manage lifetime when you don't need to conceptually.
That pointer and pointee have different life-times introduces
a global state into the program and arguing correctness becomes
much more of a hassle: every new() has to match with one and
only one delete() along each path of execution.
That's only a small part of the problem in general. If you're
allocating in order to achieve application specific object
lifetimes (which accounts for almost all of the dynamic
allocations in my code), then the problem is that the delete
must occur at the right moment (i.e. when the application logic
says that the lifetime of the object must end), and that no
pointers to the object are used after that (which is generally
best handled by some variation of the observer pattern). Using
a pointer which prevents the immediate destruction of the object
breaks the application logic, and usually doesn't solve the
dangling pointer problem satisfactorily.
Exceptions can divert the execution path at any moment to an
unknown location, and client supplied types in templates make
it unpredictable what will throw and what will be thrown. That
makes life very hard.
That's why I argued against exceptions for a long time:-).
Seriously, that's another use of smart pointers; to hold onto
the object until we can turn it over to the application logic.
You can't use boost::shared_ptr for this, since there's no way
of regaining control, but I do use auto_ptr rather often here;
in many cases, boost::scoped_ptr would also be an option.
A smart pointer like shared_ptr<> also requires global
knowledge in at least two ways: (a) we need to ensure that
no cycles occur and (b) when one relies on side-effects of
a destructor, sometimes one needs to argue that the last
pointer owning a given pointee is going out of scope.
The first is almost impossible if you use shared_ptr
religiously. On the other hand, short lived polymorphic objects
tend not to have pointers to other short lived polymorphic
objects (although pointers to entity objects are frequent), so
shared_ptr works well for them.
For me, the lesson is that one needs a set of idioms and tools
that allow us to reduce code complexity and restore the ability
to argue correctness of code locally (by looking at, say, 20
_consecutive_ lines of code at a time).
Exactly. There is no silver bullet.
Thus, I tend to wrap pointers within classes.
Most pointers will be members of a class somewhere, since the
largest single use of pointers is to navigate or express
relationships between objects. Pointers as local variables are
exceedingly rare, other than as copies of a pointer obtained
from a long lived object.
Smart pointers are just readily packaged
idioms that come up often in this context. For these reasons, smart
pointers form an intermediate layer in my library. They are used
to build other components but rarely used directly. Let me
illustrate this with a few examples.
Example 1 [statefull function objects]
=========
Interesting example. Somewhat justified, because of arguably
poor design in the standard library. (If functional objects
were passed by reference, for example, you wouldn't use this
nearly as much.) Most of the time, however, I find it
preferable to use a raw pointer to a local variable in the
funtional object, rather than allocating the actual object
dynamically; the one exception is if the actual object must also
be polymorphic.
[...]
Similar trickery can be applied to reduce the cost of
copying for large objects, in which case reference countng
becomes an invisible performance hack.
And will usually be implemented directly in the class you're
optimizing:-).
Note that shared_ptr<> is actually overkill in this context.
It's support for polymorphism, incomplete types, and a custom
deleter is not needed. A simple intrusive reference counting
smart pointer (not working with incomplete types) fits this
bill neatly.
Which is what leads to my previous comment:-).
Example 2 [deep copy pointers]
=========
C++ has value semantics. However, variables are not polymorphic.
You have to use a pointer to support polymorphism. Deep copy
pointers come as close as possible to polymorphic variables
as you can get in C++ (if only we could overload the dod-operator).
A particular example is tr1::function<>, which under the hood
is a deep copy pointer that forwards the function interface to
the pointee.
The letter envelope idiom, in sum.
Example 3 [ownership models]
=========
Smart pointers do not manage resources magically for you, but
sometimes their semantics makes enforcing an ownership model
easier.
If the shoe fits, of course... If exceptionally you do need
exactly the semantics of shared_ptr, by all means use it.
I've rarely had a case where this was the case for object
lifetime. I have had it several times for other resources, like
locks. In such cases, explicitly passing a deletor to share_ptr
fits the bill nicely; I probably have more shared_ptr with a
deletor that unlocks a mutex than I do shared_ptr with the
default deletor.
[...]
On the other hand, there are sometimes reasons to use a
smart pointer directly, although I always feel a little
uneasy. Example:
#include <memory>
class UserCommand {
public:
// ...
virtual
~UserCommand ( void ) {}
};
// magic source of commands.
// in real life, this is polymorphic.
UserCommand * getUserInput ( void ) {
return new UserCommand;
}
class MessageHandler {
public:
// ...
virtual
void operator() ( UserCommand const & cmd,
bool & do_terminate );
// UserCommand is polymorphic
virtual
~MessageHandler ( void ) {}
};
struct MyException {};
void event_loop ( MessageHandler & the_handler ) {
// MessageHandler is polymorphic
try {
bool last_run = false;
do {
// neeed for pointer because of polymorphism:
UserCommand * the_command = getUserInput();
the_handler( *the_command, last_run );
} while ( last_run );
}
catch ( MyException const & e ) {
if ( false ) {
// placeholder for things that can be
// handled here
} else {
throw( e );
}
}
}
The event_loop as written is buggy. If the line
the_handler( *the_command, last_run );
throws, we leak memory.
Even if it doesn't. This is an avatar of your polymorphic
object problem mentionned at the start; if UserCommand wasn't
polymorphic, you'd use value semantics, and be done with it.
One can use std::auto_ptr<> to rectify things:
Which is exactly what I do in this case. std::auto_ptr is
exactly what the doctor ordered here.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34