On Wed, Jul 15, 2009 at 11:31 AM, John Bytheway<jbytheway+boost@gmail.com> 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.