Re: Never ever use a raw pointer when a smart pointer can do the same
job
On Aug 14, 2:02 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
On 14 Aug, 11:25, James Kanze <james.ka...@gmail.com> wrote:
On Aug 13, 6:55 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
Victor Bazarov wrote:
Hicham Mouline wrote:
... my colleague says
"Never ever use a raw pointer when a smart pointer can do the
same job"
<snip>
[...] 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.)
what about sub-objects or resources? The high level object may
have a deterministic lifetime but the stuff it accumlates
during its lifetime has to be destroyed at the same time. Is
that a justification for a smart pointer or should you just
write your destructors correctly?
Why use a pointer at all. Stuff that belongs to the object
should usually be a member, directly, or a standard collection.
There are a few exceptions, e.g. when using the strategy pattern
internally; in those cases, if the smart pointer is handy, and
you don't have to expose it in the interface, why not.
<snip>
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.
yes! I'd noticed that. Calls in a communications system don't
vanish at the end of a block!
And they do vanish when the parties hang-up. Even if other
objects still have pointers to them.
<snip>
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.
my applications are pseudo-embedded; they very much respond to
events that are not determined by the scope structure of the
program.
Well, I was actually asking Noah, because his applications do
seem to have objects whose lifetime is determined by the scope
structure of the program, but which still have to be allocated
dynamically. My experience is more or less limited to telecoms
(pseudo-embedded, if you like---network management, mainly),
large scale business servers and GUI interfaces, and in those
fields, at least, you really have to manage lifetime explicitly.
It's part of the specification, more or less.
--
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