-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 14 July 2009, Zachary Turner wrote:
If traits are going to be supported at all, I think they should be supported first-class, and allow one to just parameterize the class with a traits class to begin with.
template<class T, class Traits=default_smart_pointer_traits<T> > class generic_shared { };
I don't intend to add additional template parameters to generic_shared. I like shared_ptr, and plan to stay as close to the shared_ptr design as possible. If you want to go the route of high configurability and multiple template parameters, it would probably be better to start from the design of Loki::SmartPtr than boost::shared_ptr. My only goal is to make an incremental deviation that adds support for more than just plain old pointers as the wrapped pointer type. Incidental to that is defining some concepts that will allow conforming smart pointer classes to use each other as their underlying pointer type. Other than that, I plan to ape the shared_ptr interface as closely as possible. It may be that I just alienate both camps, with the "simplicity" people ignoring it as too complex and the "configurability" people wanting more, but that's the road I'm on. The traits stuff in generic_shared is only intended to communicate the necessary information about a pointer-like class to generic_shared, not to provide a customization point for the wrapped type. Such customization would belong in the template parameter list of the wrapped class (the T in generic_shared<T>) anyways, not the class wrapping it. And if it were really absolutely necessary, the customization could be inserted as a wrapper class in between generic_shared and T, like generic_shared<my_customization_wrapper<T, mypolicy> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpd348ACgkQ5vihyNWuA4V67QCgnkqeKdMNV0lag3u5BfMoYnPt iyEAoJoE3fBpGkFy8YrU9aJCPMIpK9VJ =+aij -----END PGP SIGNATURE-----