From: "Jonathan Turkanis" <technews@kangaroologic.com>
Rob Stewart wrote:
Then, library users can remain oblivious to char_traits if they don't already know about it.
Or if they already know about it they can start to try to forget about it. ;-)
:-)
I've started writing some non-blocking filters, and they don't look so bad, as long as they process one character at a time. So my inclination is to make all filters non-blocking except for a couple of convenience filters which process an entire document at a time. In that case, get will always return basic_character.
You gave the caveat, "as long as they process one character at a time." What about the other case? read() and write() return numbers, not characters, right? basic_character doesn't come into play there. Are you talking about something else?
One more possibility is this:
enum eof_type { eof };
enum would_block_type { would_block };
template<typename Ch> class basic_character { basic_character(Ch = Ch()); basic_character(eof_type); basic_character(would_block_type); operator Ch () const; operator safe_bool () const; bool operator==(eof_type) const; bool operator!=(eof_type) const; bool operator==(would_block_type) const; bool operator!=(would_block_type) const;
// All the other operators we discussed };
This would allow the usage:
if (c == eof) { ... } if (c == would_block) { ... }
How do you like this?
Hmmm. You've complicated the interface still more to get that syntax, which is more verbose besides. I don't care for it since I'm happy with the look of this: if (eof(c)) ... if (would_block(c)) ... Still, if there are folks firmly entrenched in the camp that prefers the (in)equality operator for those tests, it is an excellent approach. (If you're going to fatten the interface to provide this, I suggest keeping the non-member functions, too.) -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;