Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at