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.
> 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.
>> 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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk