[boost] Re: Re: Re: Re: [iostreams] Major interace changesplanned--commentsrequested

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-03-10 17:23:01

Rob Stewart wrote:
> From: "Jonathan Turkanis":

>> I've started writing some non-blocking filters, and they don't look
>> so bad, as long as they process one character at a time. So my
>> inclination is to make all filters non-blocking except for a couple
>> of convenience filters which process an entire document at a time.
>> In that case, get will always return basic_character.
>
> You gave the caveat, "as long as they process one character at a
> time."  What about the other case?  read() and write() return
> numbers, not characters, right?  basic_character doesn't come
> into play there.  Are you talking about something else?

Oops -- I forgot to finish my overview. Right now I have InputFilter,
MulticharInputFilter, OutputFilter and MulticharOutputFilter. On top of these
are built one_step_filter (a convenience class) and symmetric_filter_adapter
(useful for converting C interfaces).

I'm thinking I'll promote symmetric_filter_adapter to a full-fledged concept
SymmetricFilter, and recommend it as the filter concept to use for
high-performance applications. I'll get rid of the Multichar filters, because
I've found writing non-blocking Multichar filters to be extremely messy; it's
just as easy to write a SymmetricFilter in that case.

So there will be three types of non-blocking filters: InputFilter (renamed
PullFilter), OutputFilter (renamed PushFilter) and SymmetricFilter. There will
also be two kinds of filters for beginners: one_step_filter, in which an entire
document is presented in a vector, and filtered version must be appended to a
second vector, and stdio_filter, in which the filter reads from std::cin and
writes to std::cout.

In the tutorial, I'll analyze each of the current example filters in detail
(except that the presidential one will just be called dictionary_filter). I'll
start by showing how to implement the algorithm using a stdio_filter, then I'll
show how to modify it to implement the more advanced filter concepts.

>> One more possibility is this:
>>
>>       enum eof_type {
>>           eof
>>       };
>>
>>       enum would_block_type {
>>           would_block
>>       };
>>
>>       template<typename Ch>
>>       class basic_character {
>>              basic_character(Ch = Ch());
>>              basic_character(eof_type);
>>              basic_character(would_block_type);
>>              operator Ch () const;
>>              operator safe_bool () const;
>>              bool operator==(eof_type) const;
>>              bool operator!=(eof_type) const;
>>              bool operator==(would_block_type) const;
>>              bool operator!=(would_block_type) const;
>>
>>             // All the other operators we discussed
>>       };
>>
>> This would allow the usage:
>>
>>         if (c == eof) { ... }
>>         if (c == would_block) { ... }
>>
>> How do you like this?
>
> Hmmm.  You've complicated the interface still more to get that
> syntax, which is more verbose besides.  I don't care for it since
> I'm happy with the look of this:
>
>    if (eof(c)) ...
>    if (would_block(c)) ...

Okay, I just wanted to get your opinion. I think I like the functions better
too.

> Still, if there are folks firmly entrenched in the camp that
> prefers the (in)equality operator for those tests, it is an
> excellent approach.  (If you're going to fatten the interface to
> provide this, I suggest keeping the non-member functions, too.)

I think it should be one or the other. So I'll use the functions.

Jonathan