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

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-03-10 15:26:39

Rob Stewart wrote:
> From: "Jonathan Turkanis" <technews_at_[hidden]>

>> Suppose you write a filter which expect ASCII characters. You might
>> want to perform arithmetic operations on characters, e.g.
>>
>>     if (c >= 65 && c < 91)
>>         c += 32; // Convert to lowercase.
>>
>> This may turn out to be pretty common. So we need +, -, +=, -=, too.
>> Also, this
>
> Those are easy enough to add, so my suggestion still works.

Correct.

> The
> unfortunate thing is that this scheme makes basic_character far
> more complicated,

Yes, I was hoping to limit the interface to a single conversion operator. I'd
hate to see someone just learning the library look up get() in the reference
section, click on the return type and be confronted with a monstrous synopsis.
Could I present a "fictional" synopsis of basic_character, which doesn't show
all the overloads, and include a note explaining the problem?

> though it can be presented progressively (start
> with ctor, safe-bool conversion, value(), good(), eof(), fail(),
> and would_block(); later discuss comparison operators; still
> later discuss numeric operators).
>
>> ignores named functions which we might want to pass a character to,
>> and the operations that a custom character type might support.

I'm thinking now it won't be much of a problem, since the conversion to char
will likely be the only admissible conversion in such cases: no one will
overload a function to take a basic_character::safe_bool, and if the function is
a template, the argument will be deduced as basic_charater.

> There's still the value() member function.

True.

>> I'm not sure if the safe-bool conversion is worth all this trouble.
>> Fortunately, it's not a majpr design change. I'll soon be writing
>> lots of non-blocking filters, and I can try both versions.
>
> I'm sorry you have to duplicate your work, but that is a good way
> to decide.  If there's no clear winner, post examples so we can
> compare them.

I don't think it will be so bad. I'll write the conditional tests using good()
instead of the safe-bool conversion, with the hope that it will work for both
versions of basic character. If it does, I can replace occurrences of good()
with the safe-bool conversion and throw out the orginal version of
basic_character.

> Whatever you choose, someone's bound to ask why you didn't do it
> another way.  I suggest adding a FAQ while the decision is still
> fresh.

Good idea.

Jonathan