Boost logo

Boost :

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,


Boost list run by bdawes at, gregod at, cpdaniel at, john at