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 class. 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, http://tinyurl.com/8axpz 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 (**ptr).socket_member_function(); 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