On Tue, Jul 14, 2009 at 6:04 PM, Zachary Turner<divisortheory@gmail.com> wrote:
On Tue, Jul 14, 2009 at 4:42 PM, John Bytheway<jbytheway+boost@gmail.com> wrote:
Zachary Turner wrote:
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. <snip>
It's interesting you should say that, because I have had exactly the reverse experience. I find free function overloads much superior to traits classes for simple things like this. For example, I think boost::hash is better than std::hash because it uses a free function and ADL to find the hashes of my classes. The main advantage is the possibility of using enable_if which allows one function overload to apply to many classes. Can you be more explicit about the problems you have had?
The most recent experience I had is in regards to providing custom validators for types in boost::program_options. I actually made a thread about this a day or two ago on this list, which you can probably find in the most recent 20 or 30 threads. But the gist of it is that I wanted to allow the user to specify an integer on the command line, and I wanted to enforce that the integer was within a certain range. Since boost::program_options has built-in support for validation I figured I'd use it. But, validation is enabled by a free-function overload on the type of the parameter. so you can provide validation for ints, validations for Foo's, etc, but you can't provide validation algorithm A for this specific command line option, and validation algorithm B for that specific command line option. It's not hard to just wait until the entire thing has been parsed and then check that each one it's in a certain range, but still, builtin support for validation has been implemented, so it would be nice if it was generic enough to handle a wide variety of validation scenarios.
Another experience I had which I also made a thread about a week or so ago was with regards to intrusive_ptr. Turns out that what I wanted wasn't _technically_ covered by the design goals of intrusive_ptr, but nonetheless it would have been possible if intrusive_ptr used ref_counting_traits with a compile-time interface mandating an add_ref and release function, rather than free function overloads. I basically wanted a way to provide different strategies for managing the same reference count on different instances of the same type. There was at least one other scenario where I was burned by this, but I can't remember it off the top of my head as it was quite a while ago.
Regarding enable_if, I didn't actually think of that. But is there a reason that if the generic class in question uses a default traits class as I suggested, that a user cannot simply provide a template specialization of that same class that uses the class template version of enable_if to achieve a similar effect?
My standard answer has now become: 1. use a traits/policy class 2. have the default traits/policy call a free functinon eg: // default free function // or yours will found by ADL if you supply your own // template<class T> bool is_null_pointer(T p) { return (p == 0); }; // default policy class, calls whatever it finds by ADL // feel free to supply your own policy class instead // template<class T> struct default_smart_pointer_traits : public smart_pointer_traits<T> { static bool is_null(pointer p) { return is_null_pointer(p); } }; Tony