>From: "Greg Colvin" <[EMAIL PROTECTED]> > 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
