Rob Stewart wrote:
I guess it looks okay with c.value(). What do you think?
I don't like it.
I don't like it either, but it does have the benefit of simplifying the code by removing all the explicit good() tests. I think explicit testing for good status is something that's going to be very easy to forget, while you're trying to write 'simple' filters that are implemented in get functions which can (effectively) be called asynchronously.
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.
But the 'simplified' form will have (c = get(src) && c.good()) everywhere, and the abstraction of algorithm state will result in more convoluted boolean expressions where testing 'good' will be very easy to omit...
You'd be relying on the conversion as a substitute for good, no?
Syntactic sugar is nice when it isn't too sweet.
Well, if it helps correctness, it isn't really sugar. Matt