"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote in message news:dnpcuo$qjn$1@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.