Re: [boost] [smart_ptr] shared_ptr template type

Subject: Re: [boost] [smart_ptr] shared_ptr template type
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2009-07-15 00:48:20

On Tue, Jul 14, 2009 at 6:04 PM, Zachary Turner<divisortheory_at_[hidden]> wrote:
> On Tue, Jul 14, 2009 at 4:42 PM, John Bytheway<jbytheway+boost_at_[hidden]> wrote:
>> Zachary Turner wrote:
>>> On Tue, Jul 14, 2009 at 1:40 PM, Frank Mori Hess<frank.hess_at_[hidden]> 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