Boost logo

Boost :

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2005-12-14 18:17:00

"Stefan Seefeld" <seefeld_at_[hidden]> wrote in message
> Arkadiy Vertleyb wrote:
> > "Jeremy Maitin-Shepard" <jbms_at_[hidden]> 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
> > 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.


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