473,883 Members | 1,692 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Poll: Do you use smart pointers?

Someone made the statement in a newsgroup that most C++ programmers use
smart pointers. His actual phrase was "most of us" but I really don't think
that most C++ programmers use smart pointers, but I just don't know.

I don't like them because I don't trust them. I use new and delete on pure
pointers instead.

Do you use smart pointers?
Sep 22 '06
92 5156

Roland Pibinger wrote:
The C++ Standard library doesn't 'new' anything what has to be deleted
by the user and, vice versa, doesn't delete anything that has been
'newed' by the user (similar in C with malloc/free). The only
exception is auto_ptr (and shared_ptr in the future) which violates
that principle.
shared_ptr doesn't call delete on your class, it invokes your deleter.
But as a short-hand, they provided a default deleter for you in case
you didn't provide one. That default one calls delete on your class.

The purpose is not to prevent you from being able to do stupid things,
the purpose is to make it easier for you to write robust code.

If you want transfer-ownership in that you want to be able take the
control away from the shared_ptr, that can be done using the custom
deleter.

The problem, which is not a problem of shared_ptr but a problem of its
use, is that it is often overused, i.e. it is used in a scope where you
know that the lifetime of the object will exist, eg a functor written
like this on a collection of shared pointers:

return_type operator() ( shared_ptr< T ) /*const */
{
// do something and return whatever
}

of course you know here that there is no need to increase the reference
count on this shared pointer because the collection holding them will
still be there as long as your pointer to it is so

return_type operator() ( const shared_ptr< T & t_ptr) /* const */;
{
T & t = *t_ptr;
// do stuff with t. If you're doing just one call on it no need for
the above.
}

avoids an unnecessary copy of the shared_ptr (which isn't trivially
cheap, and would be done for every item in your collection).

You can, in the above, potentially make the function above a template
function on its argument. Thus:

template < typename T_PTR operator() ( T_PTR t_ptr );

etc. This now decouples the functor from the type of pointer your
collection is storing.

Still, you have to understand the developers out there. They are not
always bright enough to understand all of this and I'd rather see a few
unnecessary copies of shared_ptr in code I might have to maintain than
raw pointers everywhere. Optimise later where necessary.

Sep 26 '06 #91
Earl Purple wrote:
Thomas Tutone wrote:
You're tearing down a straw man. The intrusive smart pointer in the
FAQ does not not involve any inheritance, let alone "all your classes
inheriting from one class." I described it as "perfectly adequate,"
and it is, at least for non-expert users trying to learn about smart
pointers.

Let me describe why I don't think it is "perfectly adequate". Yes, it
will probably help you avoid leaks but breaks some other fundamental
rules. I'll ignore the possible implementation of operator=() using
swap and I'll assume Fred's constructor never throws.
[code snipped]
Now I gave 3 rules. This breaks all 2 of them even as it is.It will
break all 3 if we ever decide to make it a template.

(1) If I'm allowed to separate out the implementation of FredPtr from
its interface then I could have a FredPtr with Fred being incomplete.
Change all the above into a template though (assuming that any class
that uses it has to have an accessible count_, either public or by
making the template its friend). (I'm assuming we don't have export).
That's where the option of having Fred derive from a class (that
provides the count) come in as we could get away with only having that
class complete except that we can't forwardly declare that Fred derives
from it so it would probably require a hack with casting, unless anyone
knows of a better way (other than using non-intrusive reference
counting, which is the solution).

(2) Above implementation calls delete. No option for custom deleter.

(3). There is no equivalent for a "const Fred", i.e. a FredConstPtr or
whatever you might want to call it.

Of course there is an alternative to template - you can use
auto-code-generators. In fact these are often a viable alternative, for
example on embedded systems where templates are not permitted.

Let's cut to the chase here. You make some reasonable arguments here
that the FAQ intrusive smart pointer is a naive implementation and is
not perfect.

Here is my response. The relevant comparison for this discussion is
not to a perfect smart pointer. The comparison is to raw pointers.
The OP said that he doesn't use smart pointers, and a fair amount of
bandwidth was spent by various posters on how they don't "trust" smart
pointers.

I referred to the FAQ, which includes straight-forward,
easy-to-understand code. You reasonably point out various flaws in
that code. But if the choices are a naive smart pointer or a naive use
of raw pointers, I'm still going with the smart pointer. And the
advantage of the naive implementation is that a relatively
inexperienced C++ programmer can look at the code, understand it, and
learn from it. He or she may even be more comfortable using such code
than a black-box smart pointer that meets every requirement you place
on it.

So at the end of the day - for production code, I acknowledge your
points. For learning the wisdom of using smart pointers, I hope you
will at least consider - if not acknowledge - mine.

Best regards,

Tom

Sep 26 '06 #92

Thomas Tutone wrote:
Let's cut to the chase here. You make some reasonable arguments here
that the FAQ intrusive smart pointer is a naive implementation and is
not perfect.
Here is my response. The relevant comparison for this discussion is
not to a perfect smart pointer. The comparison is to raw pointers.
The OP said that he doesn't use smart pointers, and a fair amount of
bandwidth was spent by various posters on how they don't "trust" smart
pointers.
I referred to the FAQ, which includes straight-forward,
easy-to-understand code. You reasonably point out various flaws in
that code. But if the choices are a naive smart pointer or a naive use
of raw pointers, I'm still going with the smart pointer. And the
advantage of the naive implementation is that a relatively
inexperienced C++ programmer can look at the code, understand it, and
learn from it. He or she may even be more comfortable using such code
than a black-box smart pointer that meets every requirement you place
on it.
I would agree that, if you separated the implemention from the
interface in that class and write a swap function and implemented
operator= in terms of it then the class is usable, and might even have
some uses. One, for example, being if you are writing a library that
has a function that returns a newly created "Fred" and that you wanted
to return it as a reference-counted pointer. True that the class is not
a template but you might write a code-generator if you have many
classes like this and if it generated such code with the two changes
I've suggested, it would be reasonable enough in production code (might
not be thread-safe but I guess you could write a special version for
when that is required).

In fact I would rather 3rd party library providers did provide their
own smart pointers than either forcing me to install boost or loki or
whatever or even worse, telling me I have to delete something or call
some method or other when I've finished with something. Internally they
can implement their libraries using boost and I hope they would because
that would make their libraries less likely to leak.
So at the end of the day - for production code, I acknowledge your
points. For learning the wisdom of using smart pointers, I hope you
will at least consider - if not acknowledge - mine.
Not sure what code is written for if not as production code.

My point about that smart-pointer being in the FAQ is that many,
including myself, have treated that FAQ pretty much as a coding
standard guideline, and how could I tell another developer who started
using that smart-pointer above in code that it is not really fit for
use for a couple of reasons I have mentioned when they are likely to
answer that it must be good because it's in the official FAQ.

Sep 26 '06 #93

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.