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. 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. Maybe boost already has such a thing?
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.
But whether allocation occurs inside the kernel or some C library isn't really relevant, because that memory doesn't give us a place to store a reference count. The question is whether the asio public interface should require dynamic allocation inside asio's own implementation -- and that is something I am definitely against. However, as I said, the above smart pointer solution is something I could live with, since it simply says that if an asio implementation happens to use dynamic allocation, then it may as well also support intrusive reference counting.
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).
Yep, I agree. (Except for the movable bit :) see other reply.) Cheers, Chris