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