Re: [boost] asio formal review begins

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2005-12-14 13:30:06

"Eugene Alterman" <eugalt_at_[hidden]> wrote in message

> "Arkadiy Vertleyb" <vertleyb_at_[hidden]> wrote in message
> news:dnpcuo$qjn$1_at_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?

I was under such impression...  But now when I tried this, looks like Meyers
singleton works OK, at least in VC71.

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

Right.

Still doesn't explain while socket (a low-level abstraction) should depend
on demultiplexer (a high-level abstraction), does it?

Regards,
Arkadiy