Boost logo

Boost :

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
> >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
> 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
> 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
> StoragePolicy:
> OwnerShipPolicy<
> StoragePolicy< CheckingPolicy< T >, ConversionPolicy > >

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


Check out THE C++ Seminar: 3 Days with 5 Experts

Boost list run by bdawes at, gregod at, cpdaniel at, john at