Boost logo

Boost :

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

"Eugene Alterman" <eugalt_at_[hidden]> wrote

> "Arkadiy Vertleyb" <vertleyb_at_[hidden]> wrote in message
> news:dnpe9q$vk6$
> > Let me disagree with this. There are cases when having multiple
> > each working in a synchronous way, is a better approach. First, it's
> > more intuitive, and easier to debug. Second, sometimes it's the only
> > to
> > achieve you goal, such as whan you can't (or don't want to) rewrite your
> > processing algorithm in asynchronous way.
> >
> > And when such a case arrives, it would be nice to have a clean socket
> > class,
> > without build-in asynchronisity.
> Hold on a second...
> Where has this perception that asio implements synchronous operations on
> of asynchronous come from?
> >From what I can see in docs and sources this does not seem to be the
> Notice that demuxer::run() is not called in the tutorial synchronous
> samples.
> Synchronous operations are simply implemented as regular blocking socket
> calls.

This is good. Now what's left is to remove the dependency of the socket on
the demuxer. Otherwise it's confusing: if demuxer is used, it has to be
used for some purpose, right?

Chris admitted that the socket class has built in features for asynchronous
processing. This IMO is a conceptual overhead, and reminds of MFC's CWindow
class, which is always an activeX container. Just in case.


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