Boost logo

Boost :

From: Scott Woods (scottw_at_[hidden])
Date: 2005-06-10 00:07:25

----- Original Message -----
From: "Caleb Epstein" <caleb.epstein_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, June 10, 2005 11:10 AM
Subject: Re: [boost] [Ann] socketstream library 0.7


> Why should EWOULDBLOCK be treated as an EOF? I really think this is
> trying to fit a square peg - non-blocking sockets - into a round hole
> - iostreams.
> > > Proposed Socket Library Layers:
> > >
> >
> > This is more about the big picture, stacking more complex interfaces on
> > top of it. I think we should implement iostreams for sockets first, then
> > we can go on to implement the mighty httpwistream that will give you
> > "wchar_t"s, whatever the document encoding was. :-)
> I think we should implement C++ sockets first, and then iostreams on
> top of those.
> I know there have been others that have agreed with this approach
> before. Are any of them following this thread?

Dont know if I'm in that group, but certainly agree. This subject was
in a recent thread that I contributed to; I don't imagine that that was the
first time
or that this is the last.

Having also been involved in "high speed, network-centric, message-driven
for a living" I pale at the thought of dumping the burden of iostreams on my
already busy CPUs. But that may be a response originating from or near
the spleen.

The fact that the programming model underlying iostreams is synchronous
to be acknowledged and that flaw is (in my opinion) untenable in a network
By the time all necessary changes are made to iostreams to allow it to
operate in
an asynchronous world, it would be seriously ugly. But that too is just my
as I have never implemented such a thing. Aint about to put my hand up

I like the two layer proposal, but I wonder at the class of applications
would be achievable within the sync iostream model; it might have a very


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