Christopher Kohlhoff wrote:
Hi Giovanni,
--- "Giovanni P. Deretta" <gpderetta@gmail.com> wrote: <snip>
In the end asio::socket_ptr<Stream> would look at its pointed object and decide if it needs dynamic allocation or not.
I'm happy with such a solution provided that no requirement is made that any asio class (stream_socket, etc) must support copying.
Yes, it would be in *addition* to a non copyable (but hopefully movable :) ) socket.
But let me ask: why would this need to be part of asio at all?
Consider a hypothetical smart pointer copyable_ptr<T> that works as follows:
- checks if a type trait is_intrusively_refcounted<T>::value is true, and if so is implemented in terms of intrusive_ptr<T>.
- checks if a type trait is_refcounted_value_type<T>::value is true, and if so is simply implemented in terms of T.
- otherwise is implemented in terms of shared_ptr<T>.
Then all asio would need to do is implement the type traits for its own classes as appropriate.
Would work but not as you think: the pointed object is not an asio asio::*_socket, but a set of object pointed to from the private members of asio::*_socket: a pointer to the demuxer, a "pointer" to the device (the file descriptor), a pointer to an SSL_CTX, a pointer to the buffer etc. If you look at most asio sockets, they are nothing more than that (that or I'm really wrong here!! :) ). Some of this pointers are owned by the socket (and have all the same lifetime), other pointers (the demuxer for example) are not owned. Your copyable_ptr would hold internally the full set of these pointers plus a (stateless) interface to use them (the asio::*_socket set of member functions). The whole set of pointers is reference counted (by a single counter as they all share the same lifetime). When the counter drop to zero, a deleters is called for each pointer that does the clean up (if the pointer is not owned by the copyable_ptr is not deleted). It may be the case that some types of asio::*_socket have actual internal state (instead of a pointer to state). In this case the copyable_ptr would resort to dynamically allocate the socket and refcout it. So to make copyable_ptr a separate lib, it would need formidable introspection powers to 'see' inside a asio::*_socket or each asio::*_socket should in some way (via trait classes) 'explain' its state. Because of this tight coupling i think that *if* such a class is really needed it should be part of asio. BTW, when do you plan to release next version of asio? -- Giovanni P. Deretta,