[boost] Re: [iostreams] Major interace changes planned -- comments requested

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

Jonathan