Boost logo

Boost :

From: João Abecasis (jpabecasis_at_[hidden])
Date: 2005-12-18 09:51:35

Ion Gaztañaga wrote:
>> I have now also eliminated the allocation of the socket by
>> adding a separate member to impl_type for storing the socket,
>> and changing to use shared_ptr<void> with a no-op deleter
>> object. The shared_ptr member of impl_type is now just used as a
>> token to indicate cancellation.
> Ummm, very clever move! There is no faster allocation than doing
> nothing. If you want to avoid the counter, you could use intrusive_ptr
> and the party is over.

In case you decide to go with the intrusive_ptr, I've just put up a
wrapper template, shared_proxy<T>, that attaches a reference count to a

I wrote shared_proxy specifically to cut the overhead of shared_ptr in
those cases where one controls the allocation of shared objects - you
might as well go ahead and allocate the reference count with it.

You can find the shared_proxy implementation here,

I believe the implementation to be simple and readable, alas there are
no docs for now :-(

Use case,

     #include <breeze/shared_proxy.hpp>
     #include <boost/intrusive_ptr.hpp>


     typedef breeze::shared_proxy<socket> socket_proxy;
     typedef boost::intrusive_ptr<socket_proxy> socket_shared_ptr;

     socket_shared_ptr ptr = new socket_proxy();

     // double indirection is required

While I don't think this would look nice on the user visible interface,
shared_proxy could be used in some places as an implementation detail.

[ If shared_proxy (or something like it) is considered useful, maybe I
could get away with hijacking partial specializations of intrusive_ptr,
shared_ptr and weak_ptr to make its use transparent :-]

HTH. Best regards,

João Abecasis

Boost list run by bdawes at, gregod at, cpdaniel at, john at