Boost logo

Boost :

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?
> 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at