From: pinkfloydhomer_at_[hidden]
Date: 2001-03-05 04:09:08
--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 03:13 PM 3/3/2001 +0000, pinkfloydhomer_at_y... wrote:
>
> >Would a non-blocking I/O library addition be off topic in Boost,
or
> >wouldn't it?
>
> It certainly wouldn't be off topic for Boost.
>
> But I wonder if it would actually result in a performance
improvement on
> most modern operating systems.
>
> Don't most OS's already do anticipatory buffering? Have you run
timings?
>
For me, it's not a timing issue. It's a functionality issue. In my
particular case, I am developing a chess engine (a chess playing
program), in C++. For the sake of portability, it is kept as much as
possible an adherence to the ANSI standard. My problem is, that I
have to way to listen for input from stdin non-blockingly, while
performing the search in the gamespace. So I have to use platform
specific stuff. And even worse is the fact that on the Windows
platform, this cannot be done device-independantly, but has to be
done seperately for keyboard input and piped input.
In my case, I don't really need that much functionality, I just want
to know if an entire line (ending with a \n) is in the buffer or not.
If it isn't, I ignore the input. But as soon as there is an entire
line in the buffer, I read it and act on it. I poll a number of times
a second during search in my case.
Even if I would be extremely happy to have such a feature in C++
(seeing that this feature is natively available on all the platforms
that I would ever want my program to work on), this is not just a
case of "I want this in my program, why hasn't it been done for me?
Please add it to the standard". I really think that this feature is
very general (a stream with non-blocking input capabilities), and
naturally models a huge amount of logical and physical devices on
real computers. Just as files, printing output, adding integer values
etc. is very common.