Re: [boost] Re: smart_ptr vs smart_resource

From: Rob Stewart (stewart_at_[hidden])
Date: 2003-02-25 12:33:41

From: Jason House <jhouse_at_[hidden]>
> 
>   Well, being relatively a newbie at all this stuff, I have to admit
> that the initial discussion of performing a lock using a (smart)
> pointer, seemed odd to me.  Someone later "clarified" that a smart
> pointer doesn't need to use * and -> operators...  something very
> non-pointer-like to me...
> 
> * The one argument seems to be that the name will cause confusion
> 
> * The other argument seems to be that anyone who uses it will already
> know what it means.  (either the library writer who buries the
> definition deep inside... or those who should "know" resource management
> when they hear the term smart pointer)
> 
>   As a newbie, I lean towards the first argument.  I want to learn about
> the boost libraries for future use, but I also feel that all coding
> resources should be as idiot proof as possible.  The idea being that
> people will look at the library list and not realize that they should be
> using a specific library for a seemingly unrelated problem.

This is an excellent point.  One doesn't go looking for a class
named "smart_ptr" or a library named "Boost.SmartPointer" when
looking to manage the lifetime of some arbitrary resource.  When
one uses pointers, it makes sense.

>   It is a shame for things to simply be the way that they are simply
> because they started out from a specific beginning...  

History always has a way of biting us.  In this case, we are
creating something brand new in Boost.  There isn't a PBSP in
boost.  Therefore, if it is a manifestation of a SmartResource
concept or is implemented in terms of a smart_resource class
isn't as important as the recognition that it is a special case
of the more abstract concept.

>   As far as my true stance on naming, I'm torn.  I think that the
> majority of the use really will be as as a pointer.  It almost seems
> like there can be some kind of "higher than smart pointer" resource
> management feature... something that simply restricts/prevents
> copying/access, and can call a custom resource freeing routine...  

There can still be a smart_ptr class, even if there's a
smart_resource class.  Both may be separate manifestations,
possibly sharing some implementation details, of a SmartResource
concept.  Equally plausible, smart_ptr could be implemented in
terms of smart_resource somehow (derivation, aggregation,
whatever).

Even the name "smart_ptr" will not be commonly exposed; one will
use typedefs to hide its configuration in order to leave open the
possiblity for future changes to a given SP type.  (Reasonable
policy defaults may give a good, common SP type that can be used
in most circumstances.  If that's the case, then one may refer to
"smart_ptr" rather frequently.)

Names are important.  Witness the recent discussion about whether
pointers are resources, refer to resources, or may refer to
resources.  Words convey meaning.  The wrong words confuse.  The
right words clarify.  The same is true for names.  Yes, one can
learn that "smart_ptr" means resource manager for which pointer
semantics may be appropriate.  But, far better is to have
"smart_resource" and "smart_ptr" as separate classes.  The latter
provides a superset of the behavior of the former, but the former
may be precisely what's needed in a given context.

>   With the counter examples of pointers to non-resources, would
> scoped_ptr or shared_ptr even make sense?  It seems that if there's a
> smart_ptr to something within another another object, the destruction of
> what is pointed to will never actually be controlled by smart_ptr... 

I'm not sure what you're asking here.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;