[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.. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
