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
> >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 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
> >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
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 -
> 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.
> 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< 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk