|
Boost : |
From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2005-12-19 16:56:09
Hi Christopher,
"Christopher Kohlhoff" <chris_at_[hidden]> wrote
> --- Jeremy Maitin-Shepard <jbms_at_[hidden]> wrote:
> > It seems that a possible solution is to provide a `dummy'
> > demuxer that simply makes asynchronous operations fail. This
> > `dummy' demuxer could then be the default parameter to the
> > socket constructors, thus eliminating the need to specify a
> > demuxer for synchronous-only use.
> >
> > It seems that this would indeed clean up the interface for
> > synchronous-only use.
>
> After pondering this for a few days, I've come to the conclusion
> that doing the above isn't that dissimilar to having a singleton
> demuxer. Such a demuxer would be used as the default argument to
> constructors, as Jeremy said. It certainly wouldn't be any
> different in terms of runtime performance. What do people think
> of this approach?
Could you provide some (high-level) justification of why it is beneficial to
have a socket dependency upon a demuxer?
Maybe I am missing something, but IMO such a dependency is unnatural even
for asynchronous IO. Hiding it behind default parameter, singleton, etc.,
just masks what I believe is a design problem.
If you absolutely believe this dependency is necessary for async IO, having
two separate classes, such as sync_socket and async_socket would be much
cleaner. But again, I can't see what justifies such a dependency even for
async IO.
Regards,
Arkadiy
Regards,
Arkadiy
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk