From: "Jonathan Turkanis" <technews@kangaroologic.com>
Rob Stewart wrote:
Let's review. There are several things one needs to do with a basic_character:
- return it from a function - test it to determine success - compare it to a char/wchar_t
Have I missed anything?
See below.
Given those requirements the class needs:
- value semantics - safe-bool conversion - comparisons with char/wchar_t
Therefore, I think this will work:
<snip synopsis of basic_character with lots of operator overloading>
Now you can write both of these:
if (c = get(src))
if (c == comment_char_)
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. The unfortunate thing is that this scheme makes basic_character far more complicated, 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.
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. 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. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;