Re: [boost] 36 short films about smart pointer....

[Beman Dawes]

At 05:18 PM 2/28/2003, James Curran wrote:

>    Some time ago, when we were first discussing smart_ptr, it was
>mentioned here that someone had identified 36 different styles of
>smart pointers.
>
>    Could anyone here point me to that article?
That may have been a reference to a feature model I started, but never 
really finished. See attached.

It generated over 100 different configurations. I expect that if you 
finished it with features like weak_ptr and others that Peter Dimov and 
others have developed, you would end up with thousands or tens of thousands 
of valid configurations.

--Beman

Title: Smart Pointer Feature Diagram







Smart Pointer Feature Model Diagram
The purpose of the memory management smart pointer concept is to hold a C++ built-in
pointer and to manage its memory ownership.  A smart pointer is a an
example of the "resource acquisition is initialization" technique
described by Stroustrup in "The C++ Programming Language" [14.4.1].
In a larger sense, smart pointers are not limited to memory management. 
Other roles they can play include checking, locking, loading, and navigation.
Most iterators in the standard library are examples of smart pointers even though they
don't have strong ownership semantics. 
The feature model presented here focuses only on memory management design
features.
For more information about feature diagrams, see www.boost.org/more/feature_model_diagrams.htm.

Feature Diagram

Memory-management-smart-pointer( ownership, shape, allocation,
    deletion, type-visibility, conversion-to-ptr )
  
    ownership (  unowned |  scoped |
       transferable |  shared |
       collected )
    
      shared (  detached-reference-count |
        
        attached-reference-count )
      
    shape (  non-array |  array )
    allocation (  implicit-allocation |
       user-allocation )
    deletion (  implicit-deletion |
       user-deletion )
    type-visibility ( complete-or-trivial-dtor |
      incomplete-with-non-trivial-dtor )
    conversion-to-ptr (  no-implicit-conversion |
       implicit-conversion )
  

To ease implementation, array is not allowed with attached-reference-count,
but there are no other constraints.

This feature diagram generates over 100 valid configurations.  Most, if
not all, of those configurations are actually useful in practical
applications. 

ownership

The most fundamental feature of a memory management smart pointer is how the
ownership of the pointed-to memory is managed.

  
    unowned: By supplying a "do
      nothing" user-deletion function, ownership is effectively not
      exercised. 
    scoped: The pointed-to memory is deleted
      when the smart pointer is destroyed.
    transferable: The pointed-to memory is
      deleted when the smart pointer is destroyed. Ownership may also be transferred
      to another smart pointer.  In other words, the std::auto_ptr<>
      semantics.
    shared: Ownership of the pointed-to memory
      is shared between multiple smart pointers; deletion occurs when the last
      sharing pointer is destroyed.  Does not work in the presence of
      cyclic references.
    
       detached-reference-count:
        Direct (smart pointer contains pointers to object and to count) feature
        only currently supported.  Indirect (smart pointer contains pointer
        to struct containing pointer to object and the count.) feature may be
        supported in the future.
      
        attached-reference-count: The pointed-to object must contain an
        invasive reference counter.  (A non-invasive
        attached-reference-count (count_bdy like) or linked-pointer (linked_ptr
        like) features may be supported in future revisions.)
      
    collected: Ownership of the pointed-to
      memory is shared between multiple smart pointers; deletion occurs at some
      time after the last sharing pointer is destroyed.  Does work in the
      presence of cyclic references.  AKA garbage collection.
  


shape

  
    non-array:
    array:
  


allocation

  
     implicit-allocation: A C++
      new-expression [ISO 5.3.4] will be done automatically by the smart pointer
      constructor.  Safer than user-allocation.
     user-allocation:  The user
      must allocate and supply a pointer to the pointed-to memory. 
      Although slightly more flexible, this approach is more error prone since
      errors such as passing in a pointer not allocated by a new-expression, or
      a pointer already owned by another smart pointer are possible.
  


deletion

  
     implicit-deletion: Deletion will
      be via a C++ delete-expression.
     user-deletion: Deletion will be via
      a user supplied deletion function.
  


type-visibility

C++ language rules [ISO 5.3.5] require that the type being deleted by a
delete-expression be either a complete type or have a trivial destructor [ISO
12.4].

  
    complete-or-trivial-dtor: 
      The type is complete or the destructor is trivial.
    incomplete-with-non-trivial-dtor: 
      The type is incomplete and the destructor is non-trivial.  A
      user-deletion function defined in a translation context when the type is
      complete must be supplied.
  


conversion-to-ptr

  
     no-implicit-conversion:
      operator T* is not defined for the pointed-to type T.  This ensures
      that an unwanted conversion will never occur. It is thus the slightly
      safer choice.
     implicit-conversion: operator
      T* is defined for the pointed-to type T.  This mimics built-in
      pointers, and improves readability in programs where many function
      arguments require raw pointers.
  


Acknowledgements
Portions of this discussion are based on boost mailing list postings by
Kevlin Henney.
The format for this page was patterned after Jeremy Siek's Mutex Feature
Diagram page.

Revised 13 Oct 2000

© Copyright Beman Dawes, 2000




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost