Boost logo

Boost :

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-03-09 13:44:34

Matthew Vogt wrote:
> On Wed, 2 Mar 2005 21:03:43 -0700, "Jonathan Turkanis"
> <technews_at_[hidden]> 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


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