[boost] Re: Re: Re: [iostreams] Majorinteracechangesplanned--commentsrequested

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-03-03 17:40:21

Peter Dimov wrote:
> Jonathan Turkanis wrote:
>> Peter Dimov wrote:

>>> 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?

> 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.

Right, thanks -- I've been bitten by this before. It's pretty typical of the
complications that will be introduced if filters have to be non-blocking. It
also brings up another point: none of my current tests would catch something
like this  :-*

>> 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.

The problem with -1/-2 is that I need something that will work for signed
characters and character types that are not integral, although the later should
be rare.

> 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.

Yeah ... I think it may be a general problem with writing non-blocking filters.
I guess I'm leaning towards putting non-blocking filters in an advanced section
and eliminating the non-blocking versions of get() and put().

> 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". :-)

:-)

Jonathan