[iostreams] names for non-blocking character properties
Hi All, Everybody likes naming questions, right? The thread "[iostreams] Major interface changes planned" discussed having the get() function return a type (basic_character, character or wcharacter) which can hold either a character, an EOF indication or an EAGAIN indication. My question is what I should call the functions which query the state of a basic_character. My first idea was to use bool good(character c) - returns true if c represents a character rather than EOF or EAGAIN bool eof(chacrater c) - returns true if c represent EOF bool fail(character c) - returns true if c represents EAGAIN. These functions have the same names as member functions of basic_ios. However, since fail() above doesn't mean exactly the same thing as basic_ios::fail(), I now think this is a bad idea. Here are the names I've thought of: good: good, is_good eof: eof, is_eof fail: fail, eagain, is_eagain, would_block, should_retry I also need names for the two functions called by implementations of get() to return characters representing EOF and EAGAIN. E.g., template<typename Source> character get(Source& src) { ... if ( ... ) return eof(); else return eagain(); } (They will actually return instances of types convertible to basic_character.) What do you think? Jonathan
On Mon, 7 Mar 2005 20:29:17 -0700, Jonathan Turkanis <technews@kangaroologic.com> > Here are the names I've thought of:
good: good, is_good eof: eof, is_eof fail: fail, eagain, is_eagain, would_block, should_retry
I like "good" and "eof" as they are familiar from "native" iostreams and seem to map well to the asynchronous case. I think fail is perhaps too strong in this context however, and eagain is too "unix-y". My preference for this property would be "would_block". -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein wrote:
On Mon, 7 Mar 2005 20:29:17 -0700, Jonathan Turkanis <technews@kangaroologic.com> > Here are the names I've thought of:
good: good, is_good eof: eof, is_eof fail: fail, eagain, is_eagain, would_block, should_retry
I like "good" and "eof" as they are familiar from "native" iostreams and seem to map well to the asynchronous case. I think fail is perhaps too strong in this context however, and eagain is too "unix-y". My preference for this property would be "would_block".
Thanks for your feedback. would_block is unix-y too, no? Jonathan
From: "Jonathan Turkanis" <technews@kangaroologic.com>
Caleb Epstein wrote:
On Mon, 7 Mar 2005 20:29:17 -0700, Jonathan Turkanis <technews@kangaroologic.com> > Here are the names I've thought of:
good: good, is_good eof: eof, is_eof fail: fail, eagain, is_eagain, would_block, should_retry
I like "good" and "eof" as they are familiar from "native" iostreams and seem to map well to the asynchronous case. I think fail is perhaps too strong in this context however, and eagain is too "unix-y". My preference for this property would be "would_block".
Thanks for your feedback. would_block is unix-y too, no?
I don't see how "would_block" can be construed as "unix-y" since it merely indicates that the requested operation would have blocked had it not returned that value. As for the rest of the choices, I agree that you should keep "good" and "eof," "fail" is awfully general, and I don't think it is the called function's place to tell the caller to try again (eliminating eagain, is_eagain, and should_retry). Thus, from the given choices, I favor "would_block." If you want it to read better in the source, you could make it, "would_have_blocked:" if (read(...) == would_have_blocked) Other options would be: unavailable if (read(...) == unavailable) not_now if (read(...) == not_now) nothing_now if (read(...) == nothing_now) maybe_later if (read(...) == maybe_later) Still, "would_block" seems like the right choice: if (read(...) == would_block) -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart wrote:
From: "Jonathan Turkanis"
Caleb Epstein wrote:
Jonathan Turkanis
Here are the names I've thought of:
good: good, is_good eof: eof, is_eof fail: fail, eagain, is_eagain, would_block, should_retry
.... eagain is too "unix-y".
Thanks for your feedback. would_block is unix-y too, no?
I don't see how "would_block" can be construed as "unix-y" since it merely indicates that the requested operation would have blocked had it not returned that value.
I got the name from EWOULDBLOCK. Maybe I should have said posix-y?
As for the rest of the choices, I agree that you should keep "good" and "eof," "fail" is awfully general, and I don't think it is the called function's place to tell the caller to try again (eliminating eagain, is_eagain, and should_retry). Thus, from the given choices, I favor "would_block."
Okay, thanks.
If you want it to read better in the source, you could make it, "would_have_blocked:"
if (read(...) == would_have_blocked)
This is not quite the right usage: for read, a "would block" condition is indicated simply by returning fewer than the number of requested characters. Also, I was thinking that would_block would be a function, rather than a constant, though I think it looks good as a constant and will see if I can make it work.
Other options would be:
unavailable if (read(...) == unavailable) not_now if (read(...) == not_now) nothing_now if (read(...) == nothing_now) maybe_later if (read(...) == maybe_later)
:-) I think if you keep calling read like above, the failure messages should get stronger and stronger: if (read(...) == unavailable) { } if (read(...) == unavailable) { } if (read(...) == i_said_unavailable) { } if (read(...) == are_you_a_complete_idiot)
Still, "would_block" seems like the right choice:
if (read(...) == would_block)
Okay. Jonathan
From: "Jonathan Turkanis" <technews@kangaroologic.com>
Rob Stewart wrote:
I don't see how "would_block" can be construed as "unix-y" since it merely indicates that the requested operation would have blocked had it not returned that value.
I got the name from EWOULDBLOCK. Maybe I should have said posix-y?
I wasn't quibbling over unix versus posix, just that "would block" is not a phrase that immediately connotes unix.
Other options would be:
unavailable if (read(...) == unavailable) not_now if (read(...) == not_now) nothing_now if (read(...) == nothing_now) maybe_later if (read(...) == maybe_later)
:-)
I think if you keep calling read like above, the failure messages should get stronger and stronger:
if (read(...) == unavailable) { } if (read(...) == unavailable) { } if (read(...) == i_said_unavailable) { } if (read(...) == are_you_a_complete_idiot)
LOL! -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
On Tue, 8 Mar 2005 09:47:36 -0700, Jonathan Turkanis <technews@kangaroologic.com> wrote:
Thanks for your feedback. would_block is unix-y too, no?
I'd say no, since it describes the concept (the operation would block) and not a system-level error code (EAGAIN). Admittedly there is EWOULDBLOCK on some systems as well, but thats not what I had in mind when considering the name "would_block". -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein wrote:
On Tue, 8 Mar 2005 09:47:36 -0700, Jonathan Turkanis <technews@kangaroologic.com> wrote:
Thanks for your feedback. would_block is unix-y too, no?
I'd say no, since it describes the concept (the operation would block) and not a system-level error code (EAGAIN). Admittedly there is EWOULDBLOCK on some systems as well, but thats not what I had in mind when considering the name "would_block".
I don't want to get distracted by the issue of why eagain may be inappropriate; I'd like to focus instead on what sounds good. I'm glad to hear that you like would_block. Jonathan
participants (3)
-
Caleb Epstein -
Jonathan Turkanis -
Rob Stewart