[asio] socket_stream noncopyable
Hello, I have some questions that I'm not getting answers from the documentation: Why is socket_stream noncopyable? Is it an expensive class? If it is, why?? How can I create sockets and accept them without using new on them? I'm not being able to figure it out how. Thanks, -- Felipe Magno de Almeida
Hi Felipe, --- Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
I have some questions that I'm not getting answers from the documentation: Why is socket_stream noncopyable? Is it an expensive class? If it is, why??
It's noncopyable primarily because it owns the contained descriptor, and so must clean it up on destruction. Only one object can have this responsibility.
How can I create sockets and accept them without using new on them? I'm not being able to figure it out how.
In the more complex applications that have been developed using asio, the stream socket has been a data member of some other class (e.g. a per-connection class). This larger class is long lived and therefore dynamically allocated. Although sockets can't be copyconstructible, perhaps they could benefit from some sort of move constructor? Along similar lines, I have wondered about how to specify the requirements for the callback handler function objects so that they can also be moveable. This would allow them to contain expensive resources, the responsibility for which is moved along the "chain" until the final handler cleans them up or passes ownership back to the application. Cheers, Chris
On 12/30/05, Christopher Kohlhoff <chris@kohlhoff.com> wrote:
Hi Felipe,
[snip]
It's noncopyable primarily because it owns the contained descriptor, and so must clean it up on destruction. Only one object can have this responsibility.
How can I create sockets and accept them without using new on them? I'm not being able to figure it out how.
In the more complex applications that have been developed using asio, the stream socket has been a data member of some other class (e.g. a per-connection class). This larger class is long lived and therefore dynamically allocated.
Yes, I tried this. IMO it *almost* works ok. Because it obligates me to have a class that lives throughout all the connection, what I would like to have is lots of handlers, one after the other, and each one take care of the connection and connections resources lifetimes. Although, thinking a little bit now, probably having one class that lives throughout all the connection would improve performance if it would be possible to have flexibility modifying the handler's order. How do you take care about this flexibility?
Although sockets can't be copyconstructible, perhaps they could benefit from some sort of move constructor? Along similar lines, I have wondered about how to specify the requirements for the callback handler function objects so that they can also be moveable. This would allow them to contain expensive resources, the responsibility for which is moved along the "chain" until the final handler cleans them up or passes ownership back to the application.
I think it would be the better way... sockets having auto_ptr semantics, but without the dynamic allocation.
Cheers, Chris
Thanks, -- Felipe Magno de Almeida
Hi Felipe, --- Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
Yes, I tried this. IMO it *almost* works ok. Because it obligates me to have a class that lives throughout all the connection, what I would like to have is lots of handlers, one after the other, and each one take care of the connection and connections resources lifetimes. Although, thinking a little bit now, probably having one class that lives throughout all the connection would improve performance if it would be possible to have flexibility modifying the handler's order. How do you take care about this flexibility?
I'm not quite sure what you mean by handler order here. Can you give an example?
I think it would be the better way... sockets having auto_ptr semantics, but without the dynamic allocation.
Yep, although I think moving (i.e. creation of a temporary equivalent to auto_ptr_ref) should be explicit, rather than implicit like auto_ptr. Cheers, Chris
participants (2)
-
Christopher Kohlhoff -
Felipe Magno de Almeida