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

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
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_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;