Re: [boost] Policy-based smart pointers revisisted

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-01-18 11:29:39

>From: "Peter Dimov" <pdimov_at_[hidden]>

> From: "Terje Slettebø" <tslettebo_at_[hidden]>
> >
> > I understand the concern. For one thing, we don't have template
typedefs,
> > yet, although me may get a similar effect (if not the same type) with
> e.g.:
> >
> > template<class T>
> > struct shared_ptr : smart_ptr<T, policies...> {};
>
> What are the primary strengths of a policy based smart pointer?
>
> 1. It allows users to create their own custom smart pointers.
> 2. It allows users to globally switch to another smart pointer type by
> changing a typedef:
> 3. It allows users to write generic functions that can take any smart
> pointer.
>
> (1) and (3) aren't affected by convenience wrappers, and (2) is made more
> difficult if the shared_ptr<> pictured above is used in the project.

I think there's also another concern, which may or may not apply here:
Avoiding code duplication. If it's possible to sensibly divide the aspects
of a smart pointer into policies, then instead of writing a new smart
pointer to deal with the change (e.g. from reference counted, to COM-type
reference counted), you just change that particular aspect or policy.

I understand your point about scope. If a component tries to be
all-encompassing, you might loose cohesion in the process. After all, you
could have a component, "Program", and various policies determining what the
program did. :) "Program" wouldn't likely be a very cohesive unit, though.

I'm also all for simplicity, cohesion, decoupling, do the simplest thing
that could possibly work (XP/pragmatic programmers), etc., and I'm sure
Andrei is, as well. After all, when Loki's typelists have been discussed,
he's stated that they are heavily KISSed. Others have argued that the
flexibility of MPL makes it worth it. So it's a little ironic situation. :)

I guess it comes down to which of a policy-based system, or a set of
independent smart pointers, as a total, has the best cost/benefit ratio. It
may also depend on how much variation is likely. This is a typical library
issue, anyway. I understand that the Boost smart pointers are quite
versatile, so they may cover much of the functionality needed, anyway.

> For completeness, there is also
>
> 4. Depending on the PBSP design, it might allow users to mix and match
smart
> pointers of different types.

One could also allow this with separate pointers, and as I understand,
that's already the case with the Boost ones (e.g. shared_ptr and weak_ptr
cooperating).

Regards,

Terje