Re: [boost] [asio] socket_stream noncopyable

From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2005-12-30 17:14:42

On 12/30/05, Christopher Kohlhoff <chris_at_[hidden]> 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