Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-01-07 20:51:31


At 05:17 PM 1/7/2002, Andrei Alexandrescu wrote:

>> The plumbing that can't be replaced includes public interface. The
>> framework knows too much about the public interface. The policies
should
>> be free to alter it. Much more powerful.
>
>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?

>> Able to cope with arrays, for
>> example.
>
>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. 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.

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.

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.

>I have the impression that I work under some misunderstanding, so I'd
like
>to clarify some things.
>
>Loki::SmartPtr does this:
>
>template <several policies>
>class SmartPtr : public Policy1, public Policy2,... public PolicyN
>{
> ... do stuff, use policies, coordinate policy interaction ...
>};
>
>Here I'm not positive (please confirm), but I think you are suggesting
>this:
>
>template <several policies>
>class SmartPtr : public Policy1<Policy2<... <PolicyN> > ... >
>{
> ... do stuff, use policies ...
>};
>
>If that's the case, please restate exactly, with examples, what
advantages
>are brought by the second approach. You mention direct inter-policy
>communication. I guess that is a kind of one-way, because for example
>Policy1 can "see" Policy2 but not vice versa.

Generative Programming, around page 384 talks about ways to propagate types
in both directions. I'm not sure SmartPtr needs that. It barely needs a
hierarchy at all. 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), and CheckingPolicy needing to be
available to each Policy which might add public interface. Although I'm a
bit worried there might be others; I just hit those right off when I
started to look at SmartPtr in detail.

> Well, there might be some
>sensical order in which to arrange the chaining of policies.

Maybe:

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

Although it keeps haunting me that ConversionPolicy is just a parameter for
StoragePolicy:

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

While I sketched out the code for both, I haven't tried to compile them,
and am off on a business trip the rest of the week.

I also want to see how Dave Abrahams tackles the problem via policy
adapter.

>Validation of design was another point. I believe that's a red herring.
In
>all applications of SmartPtr I know of, the smart pointer type definition

>is
>a design artifact which is never treated naively. Developers think on
what
>features they want and the resulting typedefs reflect a well-thought-out
>set
>of behaviours, rather than a hasty decision made by a junior.
>
>Of course, it would be very nice to have the design validated, but any
>effective validation complicates things a lot.

You must be thinking of something different than I am. I'm just thinking
of one or two compile time asserts. Nothing more. Doesn't the code
already do that in at least one case?

But you are right that it probably is a red herring; most or all
configuration errors I can envision will result in some kind of compile
error anyhow.

--Beman


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk