> [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Mensonides > I don't buy this argument about the "complexity of many pointer > types." I'm > not going to make a judgement on whether a few distinct smart pointers are > better than a single super pointer. I think we should have both and let > users use whichever the like better.
I think the problem with offering too many solutions to the same problem is that many users simply get baffled by the choice and use none. Take some of the people I work with, it has taken me many months just to get them to the point where they use shared_ptr. Just occasionally I see one of them write boost::noncopyable, or even boost/operator.hpp. If they had to decide whether to use shared_ptr, or slightly_faster_ptr, I think they would simply not bother. Simply, they won't make use of something unless they see quick and obvious benefits from it. And I don't think this attitude is at all unusual amongst programmers. Also, I can't see any future standard having more than one new pointer, and I can't see anything but the already widely used shared_ptr being it. > However, all smart pointers provide > basically the same interface, so keeping track of that is not that big an > issue, as the differences in interface exist because of the > various purposes > of different smart pointers. Also, because smart pointers are templates, > you already have a different smart pointer every time that you instantiate > it with a different type. The compatibility issues between smart_ptr_A<T> > and smart_ptr_B<T> can be handled without significantly more > difficulty than > smart_ptr<base> and smart_ptr<derived>. There seems to me to be a very significant difference between smart_ptr<base> -> smart_ptr<derived>, smart_ptr_A<T> -> smart_ptr_B<T>. The first is simply a cast and an attachment to the reference count. But the second requires that every strategy policy understands how to make use of every other strategy policy. i.e. for the following to work: smart_ptr<T, my_own_cloning_policy> f(); ... smart_ptr<T, my_own_counting_policy> a = f(); my_own_counting_policy needs to understand what my_own_cloning_policy does, and how to safely attach to it. The problem becomes exponential with each policy added. Not to mention heavily dependent. The other option, of simply not making such conversions possible makes for incompaible libraries, and lots of fix-up code to get around such problems. My vote is to keep things simple, and to keep shared_ptr and scoped_ptr as the only smart pointers. That said, I do like the way shared_ptr can improve itself if you give it something derived from counted_base, perhaps to compromise this method of adding variety of implementation could be extended. e.g. perhaps something derived from clonable_base could have cloning characteristics? As we've mentioned loki, is there any update on Loki -> boost integration? A quick check of the archives and nothing seems to have been mentioned since may or so. Sam _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost