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