From: "Jonathan Turkanis" <technews@kangaroologic.com>
Matthew Vogt wrote:
On Wed, 2 Mar 2005 21:03:43 -0700, "Jonathan Turkanis" <technews@kangaroologic.com> 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@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;