[boost] Re: policy-based smart pointers are EVIL!

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-04-19 10:04:01

<DKl_at_[hidden]> wrote in message
news:904AA220ACB4D211A10600104B3E85C92A82C7_at_MAIL...
> Yes, this is also true although from an interface point of view it
is
> irrelevant whether you want to or not. It is more important that you
> can't do this in the first place: If you mix components from
different
> sources it is pretty likely that different policies are used. As a
> result, you cannot [easily and efficiently] use objects from one
> component with services of the other component.

Again, it is clearly shown in MC++D how objects using policies are
initialized and assigned policy by policy, so total flexibility is
left to the policies on their relative compatibility, be it through
inheritance, conversions, template constructors, whatever. I don't see
what more flexibility one can provide.

> From an interface point of view, you don't want any form of choice!

I agree. That's what typedefs are for, and that's why template
typedefs will make things only better.

> The same principle applies to basically everything which is
> configurable an may appear in interfaces: If a polymorphic object is
> created by some service, it is probably returned using some form of
> smart pointer. Of course, if the implementer knows that it is small
a
> special allocator for small object may be used because it improves
> performance. However, the person at the other end may be supposed to
> pass this pointer to a function taking a smart pointer configured
using
> the default allocation procedure but in turn an intrusive counter.
And
> so on.

Policy-based design does not intend to instantiate huge templates all
over the place. The design would use strategic typedefs in key headers
under the control of the architects.

> For internal implementation of services choice is a good thing such
> that it is possible to tune the strategy to the specific needs. When
> it comes to interfaces choice is evil!

Of course. But that is an issue orthogonal on design with policies.

> The crucial part is "disable all others": If you have a choice which
> configuration is to be used in the interface of some component, you
> will end up with combinations which prevent interoperation between
> different components! You want seamless interoperability between
> different components and hence you don't want a choice - in the
context
> of interfaces. What happens behind the scenes is the matter of the
> component and have different choices there is often necessary.

It seems that there is a misunderstanding. You see policies competing
with interfaces, and the "evil" usage that you envision for them is
completely misguided. Policies and interfaces are complementary, as I
wrote in these exact words. Please allow me to refer you to Chapter
"Policy-based design" which is published online by informit.com. The
URL is linked from http://moderncppdesign.com/book/.

Andrei