From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-07 14:15:15
----- Original Message -----
From: "rogeeff" <rogeeff_at_[hidden]>
> > 2. In many cases the majority will be correct by default and don't
> have to
> > be supplied.
> You still either use default or need to think what to place there.
> The same with SmartPtr.
Agreed, there's a cost.
> > Take a look at how Jeremy applied it in the MTL3 prototype. That's
> > convinced me that it was not just a single design, but a valuable
> I meant 'how valuable it is for SmartPtr'.
I don't know that yet, either.
> > You may be right. I think much will be clarified when we start
> looking at
> > some actual code.
> I still did not hear a real problem/example that could not be
> implemented using independent policies. I would be really helpful for
I don't have one. It might not be a real problem.
> > I've been thinking about that one, too. I think the advantage of
> > approach is that in addition to extending the interface, you can
> also limit
> > the interface of the outer smart pointer by refusing to supply
> > interface elements in your policies. With an approach like that of
> > iterator_adaptor, you can do that to some extent by selectively
> > compile errors inside the Policy operations, but the error messages
> > as good. Wouldn't you rather see something like:
> > file, line: no operator ->() defined for boost::smart_ptr<....>
> > than some kind of static assertion failure?
> If policy does not implement some of the interface methods it still
> will be a compilation error like this:
> file, line: no operator ->() defined for MyOwnStoragePolicy<...> ...
> Even without static asserts.
I think you can only do that if the pointer is stored in the policy that
supplies operator->(). Suppose we decomposed the design further, and had a
DereferencePolicy in addition to a StoragePolicy? Actually, this might hint
at a cross-policy interaction.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk