"Peter Dimov" <pdimov@mmltd.net> wrote in message news:005f01c5547e$3e22aec0$6401a8c0@pdimov2...
Beman Dawes wrote:
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:00a201c55418$585bb2c0$6401a8c0@pdimov2...
When a socket is thrown your way, you just run it by the list and conclude that no bit needs to be set.
But that is about the same as having an other_flag, except that the name is 0 instead of other_flag.
You don't need a name because the user will never test for this category.
if( status() & other_flag ) { // OK, so what do I do here? }
The other categories have expectations attached, so testing for them makes sense.
What you might do in the code above is report the fact that an "other" has been discovered, or execute a fallback procedure, or whatever.
Giving it a name makes it more obvious that a return from status() may not have any of the other bits set.
I, as a user, wouldn't rely on the "one bit rule" anyway. Idiomatic code should work with any result from status(), as long as it makes sense. It is reasonable to expect a future status() to return readable_flag and writable_flag in addition to exists_flag (currently named !not_found_flag to preserve the one bit rule.)
It is fine with me if status() returns multiple bits set, such as your writeable/readable example. But I prefer each of file type outcomes to have a specific name. --Beman