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

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-01-07 21:54:05

>  >But the policies can alter the public interface in either design. Or
> maybe
>  >I misunderstood something.
>
> They can add public interfaces but not remove interfaces.  And the added
> interfaces won't be able to access certain features (CheckingPolicy), will
> they?

They wouldn't, although it's unclear to me as to why they'd need to.

>  >At the risk of beating a dead horse, I'll repeat that trying to
implement
>  >comprehensive array support (operator[], bounds checking...) in SmartPtr
> is
>  >a red herring. A more compelling example would be helpful.
>
> OK, say arrays are out of bounds for SmartPtr.  Then we have to add an
> ArraySmartPtr.

Let me repeat this:

SmartPtr does support arrays.

There's /no/ need whatsoever to define a new class ArraySmartPtr. What
SmartPtr consciously decided not to support, as thoroughly explained on page
183 of MC++D, is the indexing operator and pointer arithmetic. What's next?
Iterators inside a SmartPtr to array? It can go forever.

Supporting full-fledged arrays and pointer arithmetic could be done in one
of two ways:

1) Add a new policy.
2) Implement it in a StoragePolicy that might wrap another Storage policy.

Both options are accessible to the existing design. I chose to not use an
extra policy. Smart pointers to arrays are sometimes needed, but when they
are, you don't really want full-blown array with iteration and bounds
checking and whatnot. You want a buffer and you're better off with simply
calling GetImpl(sp)[index] to index into the array. I think this is
acceptable. Do you agree?

> That's what happened with the original Boost smart
> pointers; they didn't include array flavors and users kept asking for
array
> flavors.  I needed them myself in some commercial code.

SmartPtr does support arrays.

> I guess my problem is that I was hoping SmartPtr was a general tool that
> could handle virtually all smart pointer needs and then some, including
> implement all the Boost smart pointers.  It is coming as a bit of a shock
> to find it can't handle portions of what I see as a fairly basic smart
> pointer feature model.

SmartPtr supports all the Boost smart pointers. Then, I do sustain that it
supports all smart pointer needs I and others imagined, and a couple more.
It can support arrays with bounds checking and iteration if you want it to.

> That means we'll want to look to what comes afterwards to handle the full
> smart pointer feature model.  I was hoping for that right from the start.
>
> To me needing some kind of a follow-on is messy, and I'd personally be
> willing to switch from multiple to nested inheritance, if that was the
only
> thing preventing SmartPtr from being able to handle more of the feature
> model.  Particularly since that gets rid of the framework forwording
> functions which I see as a wart.  OTOH there may be more downside which
> hasn't surfaced yet.

Again, the existing design allows quite what the nested inheritance design
would. Is there a clear reason on why nested inheritance would be
preferable? I'm looking forward to that.

The framework forwarding functions are not a wart. They are needed exactly
to keep the policies orthgonal and simple in both interface and
implementation. SmartPtr provides the syntactic skeleton, the policies
provide the plumbing.

> The two things that jumped out at me were StoragePolicy
> needing to know ConversionPolicy, (or via versa depending on who is
> responsible for access interface),

Why would Storage have to know about Conversion? Tomorrow there comes a user
who wants smart pointers to arrays, but also wants implicit conversions.

Why would Conversion have to know about Storage? Why does the code that
enables/disables automatic conversion have to know on exactly how the
pointer is stored, allocated etc?

Providing a protocol for them to communicate would complicate everything -
unnecessarily, IMHO.

> and CheckingPolicy needing to be
> available to each Policy which might add public interface.

I understand your point. I think, however, that SmartPtr's interface is
quite fixed. If you come up with a compelling example of some sensible
interface functions that policies might add, functions that must use
checking, that would be great.

> OwnerShipPolicy<
>      ConversionPolicy<
>          StoragePolicy<
>              CheckingPolicy< T > > > >

Looks good - if there's a true reason to switch to such a design.

> Although it keeps haunting me that ConversionPolicy is just a parameter
for
> StoragePolicy:
>
> OwnerShipPolicy<
>      StoragePolicy< CheckingPolicy< T >, ConversionPolicy > >

I believe they are orthogonal. IMHO, the more orthogonal, the better.

Andrei

---------------------------------
Check out THE C++ Seminar:  3 Days with 5 Experts
http://www.gotw.ca/cpp_seminar/