On 2/6/06, Giovanni P. Deretta <gpderetta@gmail.com> wrote: [snip]
While Christopher can certainly answer better than i can, i think that the answer is: because it often doesn't need to be! A socket is a non copyable value based object. It doesn't need dynamic allocation and could very well be stack based (as the datagram_socket and the socket_acceptor in the example).
And it doesnt have to, I use shared_ptr to handle my sockets while not using dynamic allocation. The ability to configure a deleter makes it very easy to handle resources without using operator new and nor delete. And IMO it would be much easier than prohibing copying of the 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).
You could make the socket class hold internally a shared_ptr to a socket_impl and make it (shallow) copyable, but it would it be surprising and would require dynamic allocation(*) even if not needed.
Yes, probably always since you cant copy or move the socket...
A nice solution would be to make socket movable...
IMO, it wouldnt be a complete solution, but part of it.
(*) Not really, all copies of stream could hold a copy of socket_imp and only the last one would close it, but it would still require some sort of reference counting.
shared_ptr can be used, since it is already done and optimized to a lot of platforms. Why not use it inside the library?
-- Giovanni P. Deretta _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Felipe Magno de Almeida