From: Rob Stewart (stewart_at_[hidden])
Date: 2005-03-09 14:54:28
From: "Jonathan Turkanis" <technews_at_[hidden]>
> Matthew Vogt wrote:
> > On Wed, 2 Mar 2005 21:03:43 -0700, "Jonathan Turkanis"
> > <technews_at_[hidden]> said:
> >> My preferred solution is to have get() return an instance of a
> >> specialization of a class template basic_character which can
> >> hold a character, an EOF indication or a temporary failure indication:
> <snip synopsis>
> > How about if the character class has a safe conversion to bool which
> > returns (!fail() && !eof()) ?
> I'd really like to do this. In fact, this was my first idea of how it would
> work. Unfortunately, when I tried implementing it I realized that a safe bool
> conversion interferes with the conversion to char; only one of the two can by
> implicit. So I could have a safe bool conversion and require that users
> explcitly call c.value() (or c.get()) when they want to extract a character.
[snip example showing result of these ideas]
> I guess it looks okay with c.value(). What do you think?
I don't like it.
> > In this mode, EOF and EAGAIN handling both disappear unless you're
> > doing something clever like buffering, since in both cases the filter
> > doesn't want to do anything with the character received except return
> > it to the caller.
> This is a good way to explain how to write non-blocking filters. Correct me if
> I'm wrong, but I think the same discription applied to code which uses good(c)
> instead of a safe bool conversion.
That's the right approach: just code in terms of good(c). You
get simplified code without the oddity of asking a
basic_character for its character. The real value in the
suggestion is that one should ignore fail() and eof()
conditions in the filter. That's something you can document and
your examples can show the simplified form.
> >> V. Problems ----------------------------
> >> 1. Harder to learn. Currently the function get and the concept
> >> InputFilter are very easy to explain. I'm afraid having to understand the
> >> basic_character template before learning these functions will
> >> discourage people from using the library.
> > If you rely on the boolean conversion, you often won't need to care
> > whether the character is good(), fail() or otherwise.
> You'd be relying on the conversion as a substitute for good, no?
Syntactic sugar is nice when it isn't too sweet.
-- 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