Re: Never ever use a raw pointer when a smart pointer can do the same
job
On Aug 14, 12:50 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
On Aug 13, 5:15 pm, "Hicham Mouline" <hic...@mouline.org> wrote:
... my colleague says.
I disagree on the "Never".
Opinions about this "rule of thumb" welcome.
It's one of the stupidest rules I've heard of. The rule should
be just the opposite: "never use a smart pointer when a raw
pointer will do the job".
Here the reader will, IMHO, benefit from considering the context:
* James is one of the few who uses garbage collection in C++.
A typical programmer isn't.
I don't always use garbage collection, for many reasons.
* James is very much aware of where raw pointers "will do the
job", with a sophisticated understanding of what "the job" is.
A typical programmer isn't.
A programmer who doesn't know what a raw pointer is, and what it
should be used for, simply isn't competent in C++.
* James typically works with well-designed classes.
A typical programmer relates to classes that aren't that well
designed.
So although James' rule fits James, IMHO it doesn't fit the
typical programmer.
Sorry, it's a rule I (and all of my collegues) use everywhere.
As I pointed out in the remainder of my posting, raw pointers
and smart pointers don't really overlap; there are very few
cases where both will do the job.
For the typical programmer the main problem is to get the
programmer to apply automated and secure lifetime management,
For the typical programmer, the main problem is to get him to
understand that fundamental design issues, like lifetime, must
be decided at the design level. And the problem is not to
manage lifetime with pointers (since that doesn't work), but to
make pointer use coincide with lifetime (which generally
involves some variant of the observer pattern).
at all (smart pointers also solve other problems, such as
automated checking of availability, automated mutually
exclusive access, and so on, but such concerns are lesser
issues).
I've used smart pointers for transaction management, in one
somewhat special case, and I use them from time to time to
manage mutually exclusive access (e.g. to a singleton). I use
std::auto_ptr rather religiously for communication between
threads---you can't access through the pointer once you've
passed it to the other thread. I've also used smart pointers
(my own invasive reference counted pointer) for memory
management in cases where garbage collection wasn't available,
but using smart pointers for this is extremely error prone, and
requires a good deal of precaution. There are lot's of cases
where smart pointers are appropriate, but except for the last,
they have nothing to do with memory management issues, and never
with object lifetime issues.
But even that's stupid, in a way---smart pointers and raw
pointers are different beasts, and generally not
interchangeable. Generally, if a smart pointer will do the
job, a raw pointer can't, and vice versa (unless you have
some very stupid and useless smart pointers).
That statement relies on a sophisticated understanding of what
"do the job" entails.
If you don't know what the job is, you have a problem. A
serious problem, which can't be masked over by any simple
programming technique, like smart pointers.
For a more simple understanding, such as "can be made to
(apparently) work", it's not the case that raw pointers can't
do the job of smart pointers.
This follows from simple logic: at any point where a smart
pointer would do something extra, such as updating a reference
count, that extra action, or something equivalent and possibly
more efficient, can be done explicitly with a raw pointer.
Not reasonably. Strictly speaking, not at all; you need extra
code. But of course, you're just playing word games.
[...]
In practice, in most application level software (at least in
the domains I've worked in), most pointers will be raw,
because a smart pointer would not do the job---at least not
correctly. But most is not all, and there will almost
always be some cases where the smart pointer is more
appropriate as well.
"most application level software" is IMHO a severe
over-generalization.
Yes and no. Show me a case of application level software where
a smart pointer is the most appropriate solution, and we can
discuss whether it is frequent enough to exclude the "most" in
my statement. (I very definitely know of a few cases where
smart pointers are appropriate, but they aren't common enough to
invalidate the "most".)
--
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