Re: [boost] Re: Lock Classes: Does anyone care.

From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2003-02-20 07:20:39

[Alisdair]
> > To use an old English idiom, I think you are putting the cart before

> > the horse [as did Modern C++ Design, IMNSHO]
> >
> > Resource protection is a useful concept, and pointers are simply
> > another resource that needs protecting.  It makes little sense to
> > dereference a mutex, for instance.  This is one of the defining
> > concepts of a pointer.
> >
> > Rather, I think if we seek a generic implementation the 'base'
> > concept is resource protection, and smart pointers are a refinement
> > of this concept.

I didn't see this part of the thread before I posted in response to Gennadiy
in another branch. I was trying to make this same point some months ago when
PBSPs started to become a hot subject on boost.

[Gennadiy]

> (for example to call methods of it). Aforementioned operators could be
> very handy in this case. So I don't think that smart_ptr interface
> does not fit for the purpose of generic resource manager. In any case
> it's details of implementation, that we may discuss during pbsp
> review.

I wholly disagree that this issue is down to details of implementation. The
dereferencing operators can be seen to be implementation, but their presence
in the interface, whether compiled or not, leads to a muddled view as to the
intent of the class(es), IMHO.

However, I still say that the overriding issue here is simply that of
*name*. Smart pointers and resource wrappers are, and still increasingly so,
important concepts. Having such a confusing name->intent relationship is, to
me, very counter-productive because it makes a concept (or concepts) that
should be simplifying design into something confusing, even arcane. I'll say
it again in as plain terms as I can:

Smart pointers are examples (specialisations?) of smart resources Smart
resources are not examples or specialisations of smart pointers.

A NON POINTER resource managed by a smart POINTER is confusing and counter
intuitive.

It doesn't matter how well the interface fits.. That is not the issue
(although I do still contend that there are some issues there too, if
minor).

To me this locking class thread has been a demonstration of the clash of
these concepts.

(oh, and btw, I like the idea of the locking classes, Kevin. I do think they
could be built as policies of a smart_resource, but I don't think it makes
sense to build them from smart_ptr).

Best regards,

[)o
IhIL..