From: Eugene Alterman (eugalt_at_[hidden])
Date: 2005-12-14 12:06:31
"Arkadiy Vertleyb" <vertleyb_at_[hidden]> wrote in message
> Than have you considered putting them in a type rather than in an object?
> 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
> 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
> have to do anything with being asynchronous-enabled or not. Asynchronity
> 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
> have to accept any parameters at all.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk