"Sam Partington" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > If they had to decide > whether to use shared_ptr, or slightly_faster_ptr, I think they would simply > not bother.
But it's not just "slightly faster". This is a misconception. For example, COM or CORBA pointers are not (or at least were not) usable with shared_ptr. > 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. It turns out that they would so much more prefer a truly extensible solution. If I remember correctly, it was all about policy-based smart pointers at the last two standards meetings. For them it's all the more appealing because they can package it with template typedefs, feature that would change the slate completely. However, if the boost community does not support, or openly opposes, pbsp's, then the committee's opinion might change. > 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. I love a good argument, but when it is based. Pbsp's don't have exponential problems, they /solve/ exponential problems with linear effort. There are coherent ways to convert from one policy to another, some explained in mc++d, and some more refined ones developed later. > 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. My feeling is that the boost community would of course be interested in looking over a related submission, but most of its members are not interested in actively working on such a port. And let's face it, I'm not popular with boost, and that doesn't help generating enthusiasm inside boost :o). I don't have the time to work on a port, and the way things are shaping up, it seems like I'll never have. In the meantime, there is of course some cross-polination going on. I am personally a bit more into KISS than I probably should, which is funny given that pbsp's are rejected on grounds of not being KISSed enough :o). Andrei _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost