Re: [boost] Re: smart_ptr vs smart_resource

From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2003-02-26 04:48:27

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

[Rob Stewart]
> 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.

Yup. I'm glad that it is beginning to emerge that I am not alone in this
conviction :-)

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

In the Policy Based case smart_ptr would just be smart_resource (or
resource_manager) with certain policies (or policy sets). Template typedefs
would help a lot here.

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

Agree 100%

Thanks for you comments,

[)o
IhIL..