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-15 14:24:38

On Wed, Jul 15, 2009 at 11:31 AM, John
Bytheway<jbytheway+boost_at_[hidden]> wrote:
> Zachary Turner wrote:
>> The most recent experience I had is in regards to providing custom
>> validators for types in boost::program_options.
> <snip>
>
>> Another experience I had which I also made a thread about a week or so
>> ago was with regards to intrusive_ptr.
> <snip>
>
> OK, I understand a little better now.  In each case you want to be able
> to provide different behaviour for different uses of the same type.  I
> agree with other posters that perhaps this is a confusion between traits
> and policies.  I struggle to imagine the same pseudo-pointer type
> requiring two different meanings of what null is, but that may be a lack
> of imagination on my part :).

Yes, that was my bad.  I should have said policy and I said traits.  I
can't think of an immediate use off the top of my head either, but
with my luck it will happen someday.

>> If you want to go the route of high configurability and multiple
>> template parameters, it would probably be better to start from the design of
>> Loki::SmartPtr than boost::shared_ptr.
I don't think I was necessarily proposing something "highly
configurable".  Just "moderately configurable".  shared_ptr, for
example, allows you to specify an arbitrary delete function in the
constructor.  This is somewhat analagous to the is_null() function.
Of course passing an is_null() function to the constructor would not
be ideal because it would add even more space overhead to the class,
but shared_ptr definitely does allow per-instance customization of at
least 1 aspect of the object being contained.  So I'm not so sure I
agree that it would be straying that much from the design adding a
simple policy.  Both methods stray from the design of shared_ptr
equally, just in different ways.  In generic_shared in sandbox, half
of the object's customizability is available per-instance and half is
available per-type.  I find it a little counterintuitive that the
customizability semantics are totally different for two equally
fundamental pointer operations.  So this could certainly be considered
a deviation from standard shared_ptr behavior.  But it doesn't seem
like more or less of a deviation than adding a default policy.

I can understand the desire to keep it simple and similar to
shared_ptr.  But I guess we have to define what is considered similar
vs dissimilar.  Adding an additional argument with a default type
allows them to be used with identical syntax.  One could grep their
entire codebase, replace all occurences of shared_ptr with
generic_shared, recompile and the code would behave correctly.  I
think that's pretty similar.