Re: To use or not to use smart pointers?
On Jul 19, 6:40 pm, Glen Dayton <REMOVEday...@ieee.org> wrote:
Despite this peanut butter spread of a performance penalty,
you'd be insane to use raw pointers.
So you consider smart pointers a silver bullet. Despite the
significant extra effort it takes to use them, and the fact that
they don't solve anything most of the time, but rather introduce
new problems (like managing cycles) which weren't there before
If you habitually use raw pointers you might as well be
programming in C.
In other words, you don't have any real arguments, so you resort
to name calling.
appropriately, auto_ptr<>, shared_ptr<>, weak_ptr<>, and
brethren will eliminate all resource leaks and their attendant
problems such as memory corruption through premature frees.
So once again, you're claiming a silver bullet. Oh how I wish
it were true. I've worked a lot on applications which run 24
hours a day, 7 days a wekk, where we have contractual penalties
for down time. You can't depend on smart pointers there.
Raw unwrapped pointers provide no protection.
Nor do they provide any added problems when all you want to do
is navigate (and not manage lifetime), or when the lifetime
depends on the application logic.
Naked pointers are obscene.
More name calling, in the absense of any real arguments.
I've been explaining the advantages of smart pointers endlessly
(which are currently used in all our C++ software; we use the Boost
smart pointers) as I'm seriously concerned that there is a shift to
raw pointers. We are not developing system software but rather
normal Windows programs (with exceptions turned on). I wouldn't want
to write a C++ program without smart pointers any more but after
that endless discussion I wonder if I'm too strict.
Why on earth would you want to write the same pointer management code
over, and over again? That's not reuse... Do these fellows also write
a loop instead of using strcpy? (I've known programmers who do that.)
Any serious arguments not to use smart pointers?
"The boss will yell at you and make you remove them."
That reminded me of an ACCU article about developpers, monkeys and
This article could help as a starter for exception safety through smart
Rather than habitually using shared_ptr<>, consider using the
boost smart containers. Use auto_ptr<> as much as possible to
auto_ptr<> plays a very important roll in thread safety. You
use auto_ptr<> in your message passing interfaces, and you're
guaranteed that the sending thread will not try to access the object
when it is in possession of the receiving thread. The
advantages are enough to outweigh the disadvantage of its
preempting lifetime management (and "messages" typically don't
have to have an explicit lifetime anyway).
James Kanze (Gabi Software) email: firstname.lastname@example.org
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