Re: [boost] Smart Pointer Feature Model

From: Beman Dawes (beman_at_[hidden])
Date: 2000-07-14 06:52:08

Kevlin Henney wrote:

 > ...
 >
 >> >Also: 'unowned'.
 >>
 >>Hum... Is it still a smart pointer?  Could you explain a bit?
 >
 >Yup. Going back to square one (or should that be zero as it's C++?)
 >smart pointers are proxy objects that add management and access control
 >to a level of indirection, idiomatically appearing to support parts of
 >the built-in pointer protocol. A common application (and misconception)
 >is SPs for memory management. This is only one role that they can play:
 >checking, locking, loading, navigation, etc are others. Hence, most
 >iterators in the standard library are examples of smart pointers even
 >though they have no strong ownership semantics.

More thoughts on the above:

There is a distinction between a feature model as a software engineering 
tool, and using a feature model to create a formal classification or 
taxonomy.

C&E propose feature models as software engineering tools to aid in the 
design of deliverable software.  Thus the boost feature model for smart 
pointers would probably not include iterators since (I'm assuming, possibly 
incorrectly) the boost smart pointer generator will not generate something 
you would call an iterator.  That would be true regardless of whether boost 
uses just template magic for generation, or also uses an HTML or other 
wizard.  If it turns out that 100% of the boost smart pointers 
configurations are memory management smart pointers, maybe we should rename 
the concept memory-management-smart-pointer or similar, or at least make 
that clear in the docs.

What you are in effect saying, I think, is that the same feature model 
approach could also be used to create formal classifications.  There the 
aim is better understanding, explanation, and communication rather than 
actual working code.

But for the boost SP feature model, we should only include the feature if 
some real configurations will include it, even if only in version 2. That 
might well apply to user-supplied-locking or 
pointer-isnt-already-owned-checking, for example.  But iterators or other 
navigation smart pointers may be outside the scope, and if so wouldn't be 
included.

--Beman