Matthew Vogt wrote:
On Wed, 2 Mar 2005 21:03:43 -0700, "Jonathan Turkanis" <technews@kangaroologic.com> said:
Hi All,
Hi. Sorry I'm replying to this thread so late!
No problem -- I need all the input I can get.
My preferred solution is to have get() return an instance of a specialization of a class template basic_character which can hold a character, an EOF indication or a temporary failure indication:
<snip synopsis>
How about if the character class has a safe conversion to bool which returns (!fail() && !eof()) ?
I'd really like to do this. In fact, this was my first idea of how it would work. Unfortunately, when I tried implementing it I realized that a safe bool conversion interferes with the conversion to char; only one of the two can by implicit. So I could have a safe bool conversion and require that users explcitly call c.value() (or c.get()) when they want to extract a character.
All the filter code I've seen (mostly yours, admittedly :) ) calls 'get' in a while loop; how about instead of checking for 'good' status all the time, as in this code:
struct uncommenting_input_filter : public input_filter { explicit uncommenting_input_filter(char comment_char) : comment_char_(comment_char), in_comment_(false) {}
template<typename Source> character get(Source& src) { character c; if (in_comment_) { while (in_comment_ && c = boost::io::get(src)) { // c is not EOF or EAGAIN if (c == '\n')
if (c.value() == '\n')
{ in_comment_ = false; } } if (in_comment_) // c is EOF or EAGAIN return c; }
if (c = boost::io::get(src)) { // c is not EOF or EAGAIN if (c == comment_char_)
if (c.value() == comment_char_)
{ in_comment_ = true; return this->get(src); } } return c; } }
I guess it looks okay with c.value(). What do you think?
In this mode, EOF and EAGAIN handling both disappear unless you're doing something clever like buffering, since in both cases the filter doesn't want to do anything with the character received except return it to the caller.
This is a good way to explain how to write non-blocking filters. Correct me if I'm wrong, but I think the same discription applied to code which uses good(c) instead of a safe bool conversion.
V. Problems ----------------------------
1. Harder to learn. Currently the function get and the concept InputFilter are very easy to explain. I'm afraid having to understand the basic_character template before learning these functions will discourage people from using the library.
If you rely on the boolean conversion, you often won't need to care whether the character is good(), fail() or otherwise.
You'd be relying on the conversion as a substitute for good, no?
2. Harder to use. Having to check for eof and fail make writing simple filters, like the above, slightly harder. I'm worried that the effect on more complex filters may be even worse. This applies not just to get, but to the other functions as well, since their returns values will require more careful examination.
Actually, moving the algorithm state out of the single 'get' call is the real complication...
You're right. Thanks, Matt!
Matt
Jonathan