Christopher Kohlhoff wrote:
--- "Giovanni P. Deretta" <gpderetta@gmail.com> wrote:
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.
Looking at the current asio implementation looks like all state are pointers (even the ssl streams) or container of pointers. This means that as long as the pointed object is always the same (but its state might change) they can freely be copyied. The last reference cleans things up as usual. If you really really need non-pointer state for a particulare socket type, well, you need dynamic allocation, but only in that case. Btw, only asio::socket_ptr<> would pay for the eventual dynamic allocation, asio::*_socket would not.
- 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.
No, you make an asio::socket_ptr<asio::buffered_read_stream<
asio::ssl::stream<asio::stream_socket> > >. Only the resulting
object need reference counting. In the end asio::socket_ptr<Stream> would look at its pointed object and decide if it needs dynamic allocation or not. If it does it dynamically allocates it and it is *exactly like* a shared_ptr<Strem>, if it does not (all state are pointers), it keep the object as internal state and behaves as a collection of shared_ptrs to the pointed to objects. BTW, in the end you always have dynamic allocation. There is no way around it. But it usually it happens inside some C library (SSL_CTX for example or win32 SOCKETS) or in the kernel. So the point is not preventing dynamic allocation at all, but preventing unneeded extra allocation. This complicates the desing a lot, so I'm not arguing that it should be done (in fact i'm strongly in favour of the current interface, plus movable sockets), but I think that *if*, after some experience with asio, dynamic allocation of sockets is really needed *and* it is a real bottleneck, it can be done as an optimization (with asio::stream_ptr). -- Giovanni P. Deretta