[boost] [iostreams] non-blocking i/o : revenge of char_traits

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-04-16 19:15:32

Hi All,

I announced casually in the iostreams docs that the first release would include
hooks for non-blocking and async i/o, so users wouldn't have to rewrite their
filters when these models were fully supported. Then I spent months worrying
about the best way to implement it, and finally solicited advice here few weeks
ago.

The main idea was to have get() return a class type (basic_character) capable of
holding either a character or one of two special values representing EOF and
EAGAIN. After receiving some good suggestions, I implemented basic_character
last week, and unfortunately found some serious usability problems, especially
relating to the conditional operator. As I considered various possible changes
to basic_character, I made (as they say on Court TV) a gruesome discovery:
basic_character was starting to look more and more like char_traits.

Since it's pointless to replace one horrible bloated class with a completely
different one, I'm considering defining a template boost::iostreams::char_traits
which extends std::char_traits and adds a would_block() function. The return
type of get() would remain char_traits<>::int_type. Users writing templated code
would test the return type against char_traits<>::eof() and
char_traits<>::would_block() using  char_traits<>::eq_int_type; users writing
narrow- or wide-character components could use the convenience constants
boost::iostreams::WOULD_BLOCK and boost::iostreams::WWOULD_BLOCK, in addition to
EOF and WEOF.

The main technical problem is I'd have to pick values for WOULD_BLOCK and
WWOULD_BLOCK separately for each supported standard library.

What do people think?

Jonathan