"Stefan Seefeld" <seefeld@sympatico.ca> wrote in message news:43A09D3A.2030908@sympatico.ca...
Arkadiy Vertleyb wrote:
"Jeremy Maitin-Shepard" <jbms@cmu.edu> wrote
The key problem with that approach is that a `thin' wrapper over the platform APIs is basically useless for implementing asynchronous operations, because asynchronous operations must be implemented in widely different ways on the different platforms.
For synchronous operations, it happens to be the case that every platform provides basically the same interface, so at least a portable (but not necessarily very good) interface can be created through only a thin wrapper.
Then maybe it would make sence to define this kind of API for synchronous operations, while asio encapsulates asynchronous IO using a higher-level abstraction. The socket class would be cleanned from the asynchronous stuff, and used by both asio and synchronous API.
For me a 'socket class' is two things (let's ignore datagram sockets in this context): a way to create socket endpoints, as well as manipulate associated options, and on the other hand some means to read and write.
So, this right away leads you to sync_socket and async_socket. What if the read/write operations (ones that make the distinctinction between sync/async) were factored out? Then you would have a socket class to create socket endpoints and manipulate associated options, and (a)synchronicity would be defined by the operations applied to this socket. Regards, Arkadiy