Boost logo

Boost :

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2003-01-20 15:12:25


"Sam Partington" <Sam.Partington_at_[hidden]> wrote in message
news:NDBBIABHPAACPOAKLJBHEEOGDOAA.Sam.Partington_at_codescape.com...
> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk