Re: [boost] asio formal review begins

From: Eugene Alterman (eugalt_at_[hidden])
Date: 2005-12-14 12:06:31

"Arkadiy Vertleyb" <vertleyb_at_[hidden]> wrote in message 
news:dnpcuo$qjn$1_at_sea.gmane.org...

> Than have you considered putting them in a type rather than in an object? 
> I
> mean defining them as static functions inside a class, and then providing
> the typedef to this class as a part of your configuration, depending on 
> the
> platform used?  This is better than singleton, since your library could
> remain header-only.

Are you implying that a singleton cannot have a header-only implementation?

>> > Why is the ability to perform asynchronous operations a
>> > property of socket?
>>
>> I chose to make asynchronous operations part of asio's socket
>> interfaces because, in my opinion, having them there offers the
>> best ease of use and gives maximum flexibility to provide
>> efficient implementations portably.
>
> See, this doesn't look intuitive to me.   I am by no means a networking
> expert, but I have done some work with sockets.  And, IMO, a socket 
> doesn't
> have to do anything with being asynchronous-enabled or not.  Asynchronity 
> is
> about how the socket is used, not about the socket itself.

But asynchonous i/o implementation does depend on the underlying socket API 
(platform traits, as you call it).
Some implementations prvovide asynchronous operations while on others they 
need to be emulated by non-blocking socket calls and a reactor framework.

> If you split demuxer from platform traits, and free the socket
> implementation from the asynchronisity, moving it outside, than all the
> socket needs to know about is platform traits.  This could be used as I
> suggested above (through the typedef), and your socket constructor would 
> not
> have to accept any parameters at all.