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
> Zachary Turner wrote:
>> The most recent experience I had is in regards to providing custom
>> validators for types in boost::program_options.
>> Another experience I had which I also made a thread about a week or so
>> ago was with regards to intrusive_ptr.
> 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk