On 2/6/06, Giovanni P. Deretta <gpderetta@gmail.com> wrote:
The problem is that a socket is *conceptually* not copyable. Even if you have multiple handles to it, they all refer to the same underlying stream. Standard streams are not copyable for the same reason. If you want different objects to *share* a socket you use a shared_ptr and dynamically allocate it.
IMHO it is not true that a socket is *conceptually* not copyable. In every platform I use copying sockets are a very intuitive operation. Couldnt a socket be *conceptually* a reference counted resource? What, IMO, a socket is *not* is a resource that uses dynamic allocation. There's no point in using new operator to allocate memory for a socket!
Only if you need the lifetime of the object to be dynamic (as the example does, but it is *not* always the case) you directly allocate it. Or make it be a member of a class that is itself dynamically allocated.
Even making it a member of the class you'll probably need it to be passed along to another class, which is impossible without copy-construction. Which would need the socket (or the class that owns the socket) to be dynamically allocated and its lifetime to be watched (maybe through shared_ptr).
well, you could hold a shared_ptr (with a null deleter) to the socket or class that owns it and have its lifetime be watched by weak_pointers. This way no dynamic allocation is needed. If you want the lifetime to be dynamic, that is "as long as some one has a reference to it", use dynamic allocation an shared_ptr.
My point is that it shouldnt be needed to use dynamic allocation to use a socket. Even if you need to share it. [snip]
Yes what? Always what? Are you talking about always needing dynamic allocation? Definitely not. I've written code that uses asio stream_sockets without using dynamic allocation nor moving nor sharing ownership.
If you could show me maybe it could explain a lot of what you mean. Can you show me any code and what is its use case?
Why not? If you want shared ownership you dynamically allocate, there is no way around it. If you want to give up ownership (to move the object a long a chain of functions implementing a state machine for example), you move it.
I cant see why shared resource ownership must imply dynamic memory allocation, IMO it only makes sense to use dynamic memory allocation when the shared resource is memory. But not when it is a socket, or file or anything else. Using dynamic memory allocation when it is not really conceptually needed is a cost that, IMHO, doesnt make sense.
Well, I'm sure asio uses it in lot's of places :) ... if you mean asio should use it to implement reference counting of the underlying socket_impl, yes, it could do it *if* you decide to make the socket copyable (and I think it the wrong choice).
IMO, should be both.
BTW, I might have misunderstood some (or all) of your reply and be arguing about the wrong thing. Sorry if it is so :)
I think you got it right. But I'm still not getting how you solve most of the use cases for asio without relying on dynamic memory allocation or why you believe it should be needed dynamic memory allocation on these cases.
-- Giovanni P. Deretta
thanks, -- Felipe Magno de Almeida