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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-01-11 14:50:41

At 04:49 AM 1/11/2002, Andrei Alexandrescu wrote:

 >> I won't question your decision to not support the *_array versions by
 >> default since I mostly agree with it.
 >>
 >> But don't you think that the smart_ptr power user should be able to 
make
 >an
 >> [] supporting pointer using a policy? (This is a specific instance of a
 >> general problem: adding features to smart_ptr using a policy.)
 >
 >That kind of flexibility is a cool thing, though of course it shouldn't 
be
 >forgotten that a smart pointer is a smart pointer, not a kitchen sink.
 >
 >Creating a StoragePolicy that inherits the default StoragePolicy, uses
 >delete[] and defines operator[] and some arithmetic is easy (10-15 lines) 
-
 >and certainly a thing to do. By popular demand, I'm implementing an
 >ArrayStoragePolicy that does exactly that.

Be careful.  There is an interaction between operator[] and 
ConversionPolicy.  For an array, if the ConversionPolicy will cause 
operator T* to be supplied, then operator[] should not be supplied.  In 
other words, inter-policy communication is needed.

 >The thing is, you'd want to use CheckingPolicy before you do a 
dereference.
 >And the problem raised by Beman comes up: how do you get StoragePolicy's
 >operator[] to use the CheckingPolicy to check the pointer?
 >
 >The more I think of it, the more sense makes to enable free inter-policy
 >communication.

Stuck in a hotel room several nights this week, I've been studying the 
Loki::SmartPtr code a bit more.

I keep coming up with cases (some more likely than others) where some form 
of communication between StoragePolicy, CheckingPolicy, and 
ConversionPolicy is either useful or necessary.

I looked at making CheckingPolicy and ConversionPolicy policies of 
StoragePolicy, and that seems to work, but there may well be other ways to 
relate the three which are better.  I need to read Peter Dimov's recent 
posts more carefully.

On the other hand, the only case I can come up with where those three need 
to communicate with OwnershipPolicy is to disallow certain configurations 
like arrays when the OwnershipPolicy is invasive reference counted.  But as 
we previously discussed, these errors will be detected by compiler 
diagnostics, so we don't have to do anything special in the way of 
inter-policy communication.  Your present design WRT Ownership/other policy 
separation seems to work well.  I don't want to toss your orthogonality 
arguments out the window; if there isn't a specific benefit to inter-policy 
communication, the orthogonality rationale is a good reason to keep them 
separate.

 > Would be cool to implement that without complicating the
 >policies' interfaces.

Yes.

--Beman