Re: [boost] [smart_ptr] shared_ptr template type

Subject: Re: [boost] [smart_ptr] shared_ptr template type
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2009-07-14 18:04:25

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?