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 15:27:09

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.  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