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