Re: [boost] Re: Re: [iostreams] Major interacechangesplanned--commentsrequested

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-03-03 17:23:39

Jonathan Turkanis wrote:
> Peter Dimov wrote:
>> Jonathan Turkanis wrote:
>>
>> [...]
>>
>>> For example, if I rewrite the following to use read instead of get
>>>
>>>    template<typename Source>
>>>    character get(Source& src)
>>>    {
>>>        character c = io::get(src);
>>>        if (c.good() && c == comment_char_)
>>>            while (c.good() && c != '\n')
>>>                c = io::get(src);
>>>        return c;
>>>    }
>>
>> Yes, you are right. A "proper" in-place read-based filter that
>> implements the above (minus the bug)
>
> Care to share the bug with me? ;-)  I know that the comment character
> is checked twice, but this seems harmless.

If the first get() returns comment_char_ and a subsequent get() returns 
EAGAIN before \n is encountered, the next call will return the rest of the 
comment. You need to remember the "we are in a comment" state. I think.

>> is much, much harder to write and
>> understand. It will also be much, much faster,
>
> Actually the distinction between an in-place filter and a filter
> which produces a modified copy of its input is separate from the
> get/read question. I'm going to provide optimized treament for
> in-place filters (this is one of the planned changes that's been on
> hold), but not all filters can be represented that way. It's
> especially useful for filters which only observe their input, such as
> line- or character-counting filters, or filters which implement an
> offset view of the downstream device.

I think that all character-based filters can be represented as in-place 
read-based filters.

>> but the character version may be fast enough for most uses.
>
> So all things considered, do you think the basic_character
> abstraction makes the get() function and the InputFilter concept
> unreasonably complex?

I'm not sure. -1/io::eof for EOF and -2/io::again for EAGAIN seem good 
enough to me.

I tried to rewrite your comment skipping filter using -1/-2, and it turned 
out surprisingly complex. I'm no longer sure that the character version is 
much easier. As with my previous read-based attempt, it exceeded my 
capability to write code in an e-mail message. ;-)

Time for a contest. "Write the best non-blocking comment skipping filter". 
:-)