Re: [boost] Re: Loki SmartPtr study: Policy orthogonality issues

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-01-07 14:32:54

At 02:19 AM 1/7/2002, rogeeff wrote:

 >--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
 >
 >[...]
 >
 >>
 >> *  Some Ownership policies, such as for an invasive reference
 >counted
 >> pointer, need to disallow arrays.  The appropriate enums to
 >communicate
 >> is_array and disallow_array need to be added to StoragePolicy and
 >> OwnershipPolicy, and a compile time assert needs to be added to
 >framework.
 >>
 >
 >Could you please add a couple words more here? Why Ownership policy
 >would need to use checking policy directly? Before considering
 >different ways to implement compunication between policies I would
 >like to see a real problem/example that could demonstate the need for
 >some policies to comunicate. Form my stand point it should be either
 >generic enough to be a part of framework or part of the wrong policy
 >or the interface problem (though I could be wrong).

There's two issue intertwined in your question.

First, should policies communicate directly via an inheritance hierarchy or 
indirectly via the framework?  That's the main issue being discussed in 
most messages in this thread.

Second, how much effort should go into validation?  The cost of policies 
not communicating some configuration information (either directly or with 
the framework) is an inability to detect configuration errors.

The specific error mentioned above was specifying an array style 
StoragePolicy with an invasive reference counted Ownership policy.  That's 
a configuration error.  It will probably result in a compile error, but a 
validator could diagnose it explicitly.

A similar example would be specifying a handle style StoragePolicy with an 
invasive reference counted Ownership policy.  That would be a configuration 
error, at least for most common handle styles.

--Beman