--- "Giovanni P. Deretta" <gpderetta@gmail.com> wrote:
Felipe Magno de Almeida wrote:
On 2/7/06, Giovanni P. Deretta <gpderetta@gmail.com> wrote:
Along side the current non-copyable (but maybe movable) stream_socket asio could provide a stream_socket_ptr that would behave as if it were a shared_ptr to a stream_socket (that is, pointer semantics), but it wouldn't actually allocate a stream_socket (similar to the way an optional looks like a pointer but actualy is stack based).
It is nice, but it wouldnt need to behave like a pointer, syntactically speaking. It should have the same interface as the proper stream_socket, IMO. Only the copying being different.
Well, it behaves like a (smart) pointer (the last to exit closes the door) so it should look like a (smart) pointer. Why do you think it should have the same interface of a stream_socket? What advantages would give you?
(Btw, technically it would have the same interface, but you would call members functions using -> instead of . )
This idea has a couple of issues that I can see: - It does not allow an implementation to store additional state inside the socket object directly, so forcing a dynamic allocation on the implementation. - It does not address stream layering, as in: asio::ssl::stream<asio::stream_socket> s; or asio::buffered_read_stream< asio::ssl::stream<asio::stream_socket> > s; Each layer adds its own state, and the whole lot would need to be reference counted. Cheers, Chris