Re: Never ever use a raw pointer when a smart pointer can do the same
job
On Aug 13, 6:55 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
Victor Bazarov wrote:
Hicham Mouline wrote:
... my colleague says.
I disagree on the "Never".
Opinions about this "rule of thumb" welcome.
What's the definition of "the same job"? They are for
different jobs. Can a screwdriver do a chisel's job? Could
you drive a screw with a chisel? What do you do if you
don't have a light crowbar, but have a strong screwdriver
near-by? So, I say, bullsh!t. I use raw pointer when I
need to use a raw pointer and I use a smart pointer when I
need to use a smart pointer.
What purpose does a raw pointer serve?
Navigation.
Almost any case when you need a heap allocated data blob can
be solved by the use of raii objects such as std::vector or
wrapping such allocations in a smart pointer such as
scoped_ptr, shared_ptr, or even std::auto_ptr.
That's not the case in any of the applications I've worked on.
At the application level, lifetime is generally very
deterministic; objects are created and deleted as a result of
specific input from external sources. Using a scoped_ptr,
shared_ptr or an auto_ptr on any of these will result in a
double delete. (It's sometimes useful to use an auto_ptr during
the actual construction, until the transaction has completed, or
the object has been registered wherever it has to be
registered.)
Conceivably, there would be a use for a smart pointer which
works the opposite of garbage collection---deleting the object
causes the pointer to be null'ed. My site (when it was
accessible) had a ManagedPtr for that. In practice, however,
this is really only useful for 1->{0,1} relationships, and not
always for those (the object containing the pointer often has to
react to the fact that the pointed to object has disappeared); I
don't think I've used this smart pointer more than once or twice
in the more than ten years since I implemented it.
If any of those object do what you need you should use them
because NOT using raii leaves you with all the problems raii
answers.
RAII isn't really very appropriate for managing the lifetime of
dynamically allocated object, since RAII depends on lifetime
corresponding to a scope, and if the lifetime of an object
corresponds to a scope, then you don't allocate it dynamically.
In certain cases, shared_ptr can serve as a poor man's garbage
collector, but it's very error prone (compared to a real garbage
collector).
Most times when you want to pass a raw pointer it's because
you're actually wanting a simple reference to some externally
owned data. Most of these cases should be resolved by using
exactly what you want: a reference.
Unless it's an optional argument, where you might want to pass
a null pointer. But I agree with you in general---when passing
arguments, prefer references to pointers when possible. Most
pointers end up in the objects, themselves---class member
variables---where they are used for navigation. And must be
reseated, so references are out. A lot of the relationships
expressed by pointers are 1->n, which means some sort of
container of pointers---std::vector< T* >, std::set< T* >,
std::map< IdType, T* >, etc.
The only case when this is not possible is when you are
creating an object that:
a) needs an assignment operator that does a shallow copy (or
anything else where you'd override the reference without
assigning to the object you're referring to)
b) can't initialize the reference upon construction.
Or have to reseat it.
c) You're not allowed to ignore warnings and aren't allowed to
override the "assignment operator could not be created"
warning (in which case a reference will break the coding
standard you're working in)
Note that not all uses of a pointer are solved by a smart
pointer but most uses ARE solved by the use of something
besides a raw pointer.
There are exceptions to any standard. I think a standard that
says, "Wrap every raw pointer in an RAII object," is a good
standard that allows the team to dictate when to override (not
the whim of some stubborn developer who thinks they don't need
RAII). The standard given, "...when a smart pointer can do
the same job," seems to maybe be even better since it dictates
exactly when to use a smart pointer and when not to. On the
other hand, it seems to leave question of definition about
when a smart pointer can do the same job.
I'd be willing to entertain arguments to the contrary but the
project I'm managing uses such a standard and I've yet to see
a convincing argument that it's a bad one. We have our
exceptions when we need them (such as working with WX) but
generally wrap any pointer creation into some sort of smart
object that will delete it at the right time.
I'm curious as to the type of software you work on. You
obviously have some experience, but in all of the application
software I've seen (low level libraries are a different case),
dynamically allocated objects which have lifetimes corresponding
to those of a local variable are extremely rare---almost all
have lifetimes which begin and end in response to an external
stimulus. And almost all pointers are used for navigation, and
only navigation.
--
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