[boost] Re: smart_ptr vs smart_resource

From: Jason House (jhouse_at_[hidden])
Date: 2003-02-20 17:33:22

  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.
  It is a shame for things to simply be the way that they are simply
because they started out from a specific beginning...  

  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...  

  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... 
What am I missing?

Phil Nash wrote:
> 
> > > [Anthony Williams]
> > > > On Windows, for example, you can use GlobalAlloc to
> > > allocate some memory,
> > > and
> > > > you get an HGLOBAL back --- a handle to the memory.
> [..]
> > > This sounds like a perfect case where using a smart_PTR would be very
> > > confusing, maybe dangerously so!
> 
> [Gennadiy]
> > The only place where you will see usage of the name smart_ptr is somewhere
> > deep in library code:
> >
> > typedef smart_ptr <...> GlobalMemoryHandler;
> >
> > After that you will use non-confusing name GlobalMemoryHandler.
> 
> It may work out that way in this case - but why not make the name
> non-confusing in the first place?
> You appear here to concede that it *is* confusing.
> We are talking about smart_ptr and a potential smart_resource concept - not
> GloalMemoryHandler - that was just an example of where the naming becomes
> particularly confusing - whether it is buried deep in library code or not.
> 
> I still have yet to hear why you do not like the idea of putting these
> concepts in their appropriate order?
> 
> Thanks for your comments,
> 
> Regards,
> 
> [)o
> IhIL..
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost