Re: [boost] Policy-based smart pointers revisisted

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-01-18 13:47:50

>From: "Greg Colvin" <Gregory.Colvin_at_[hidden]>

> At 07:33 AM 1/18/2003, Peter Dimov wrote:
> >
> >It is not simply declaration complexity that Dave's talking about - it
can
> >be avoided by making smart_ptr<T> be shared_ptr<T> by using default
> >parameters. It is semantic complexity. shared_ptr is fairly deep by
itself
> >(and getting the specification and the tests to a state that can be
> >considered adequate wasn't easy.)
>
> One aspect of the semantic complexity that bothers me
> is that the various flavors of smart pointer may not
> be interchangeable.  shared_ptr is partly parameterized
> on implementation, but the interface and semantics
> remain the same.  For a policy-based smart pointer
> to be usable I think you need a clear set of concepts
> that clients can use as requirements, and a clear
> delineation of which combinations of policies support
> which concepts.

Good idea. This is what I hinted to with providing convenience
typedefs/classes, which guaranteed correct, and documented, semantics. C&E
distinguishes between the Configuration DSL and the ICCL (Implementation
Component Configuration Language). The former is geared towards the user,
and embodies application domain knowledge, while the latter is geared
towards the implementation, with knowledge about that. Then you have a
generator to bridge the two.

Policy-based design is typically mostly ICCL, with it being a kind of
special case of GenVoca, as Mat Marcus has mentioned. There's typically
little or no functionality such as that provided by a Configuration DSL.

If one had more functionality like that, it could make it easier to use, and
you shouldn't have to be an expert on the implementation of the smart
pointer, to be able to choose correct policies, and avoid any invalid
combinations or pitfalls.

This reminds me that I'll read up on the discussion regarding policies, in
the Boost archive.

Regards,

Terje