On Tue, Jul 14, 2009 at 1:40 PM, Frank Mori Hess<frank.hess@nist.gov> wrote:
So, before I spend any more time on it, is this something worth pursuing further as far as boost goes? Does it stand any chance of making it into the smart_ptr library? Is there a silent majority out there who thinks this is a worthwhile idea, or is it just me? I might even settle for a vocal minority :)
I would use the heck out of something like this. However I was disappointed to see in the comments that the null_value member was replaced by a search for a free function lookup. 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. Every example in boost that I can think of off the top of my head where something relies on either a free-function overload or a template specialization of something (which admittedly isn't too many, but at least 2 or 3 anyway) I have always encountered limitations in in my own usage and had to roll my own similar class for some specialized usage. Maybe this has been discussed in similar contexts before and there's some general consensus, but why not just (note this code assumes that all specializations of smart_pointer_traits in the version in sandbox remain unchanged): template<class T> struct default_smart_pointer_traits : public smart_pointer_traits<T> { static bool is_null(pointer p) { return (p == 0) ? true : false; } }; template<class T, class Traits=default_smart_pointer_traits<T> > class generic_shared { }; As long as the interface required of a traits class is very small, then the class still remains equally simple to use. I don't have an immediate use case in mind for wanting two different instances of generic_shared<> to check for NULL differently, but I know I've been burned more than once in the past by classes requiring free function overloads, so I just want to address it in advance. Zach