From: Rob Stewart (stewart_at_[hidden])
Date: 2005-03-10 10:32:12
From: "Jonathan Turkanis" <technews_at_[hidden]>
> 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
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
-- Rob Stewart stewart_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk