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