Re: Best Practices For Thread-Safe errno
Le Chaud Lapin wrote:
On Oct 12, 3:38 am, Seungbeom Kim <musip...@bawi.org> wrote:
Some functions have more than a simple success/failure to say:
e.g. what if you requested to send 200 bytes and only 100 bytes could
have been sent at the moment? Is that a success or a failure?
The programmer would have to decide, but to me it smells like success.
The programmer on which side?
It is the implementer of the function, not the user, that decides
what to return, true or false.
Note that my primary reason for going the unsigned route would not be
to capture the other 2GB linear space, though that would be an
influence. My primary reaosn would be to move into a regular mode of
thinking regarding function calls. I seek mental relief. IHMO,
true=success/false=failure provides greater mental relief. It "reads"
better than the other models like "< 0 means error."
As mentioned elsewhere in this thread, there are other conventions
that are equally regular, equally consistent. It's perfectly fine
that you like one of them better than the others, and I don't have
a big objection to that convention either, but it's not fair to
criticize other conventions by a particular example that is worsened
by other factors as well.
There is a bit of intermingling of computer/human semantics of
language at play here. It is the same principle that drives a library
designer to prefix the name of a member function with the word "is".
He anticipates that users of his library will be using it in certain
way, and he accommodates the mode of thought in the user of his
library:
bool Digital_Address:is_archaic() const;
Digital_Address da;
if (da.is_archaic()) // this reads well. subject/predicate/object
// yada...
This is fine, since the name of the function obviously dictates
what each of the possible return values means. That's the case for
adjectives, possibly prefixed by "is". I would be very confused
if [is_]empty() returned anything else than true for empty and
false for non-empty. But this is not an example of success/failure,
for which there is not a single correct convention.
if (obj.do_something(args))
/* success */
else
/* failure */
I don't find the above particularly easier/better read than the below:
if (obj.do_something(args) < 0)
/* failure */
else
/* success */
for "if obj do something" is not as grammatical or logical as
"if obj is empty/running/finished/whatever_adjective/etc."
(Of course, the most unambiguous is to use exceptions:
try {
obj.do_something(args);
/* success */
}
catch (exception&) {
/* failure */
}
but it's a different story.)
I got into had a bad experience regarding "How Well Does It Read?"
recently:
[...]
DllCanUnloadNow
http://msdn.microsoft.com/en-us/library/ms690368(VS.85).aspx
[...]
Microsoft writes at beginning of the man page:
"If the function succeeds, the return value is S_OK. Otherwise, it is
S_FALSE"
Then at the end:
"DllCanUnloadNow should return S_FALSE if there are any existing
references to objects that the DLL manages."
A careless programmer [moi], might make a mistake, and say, "S_FALSE
is one of the values...so...S_TRUE, or just TRUE must be the other. I
will return TRUE if it is OK to unload."
And that's what I did. I return S_FALSE when there were existing
references, when it was not OK to unload, and TRUE when where not, so
that TRUE meant "OK to unload."
Then someone, perhaps moi again, saw the S_FALSE several months later
and removed the "S_", so that, if it was OK to unload, we were
returning TRUE, and FALSE, if not.
But in Windows, TRUE has value 1. S_FALSE, also has the value 1. FALSE
has value 0, S_OK has the value 0.
*** Note that S_OK == 0 derives precisely from the principle that 0
should ne "no error", as said by some in this thread. ***
I'm not sure if I am included in the "some" you mentioned, but I didn't
argue that 0 "should be" no error. My argument is that it is a valid
convention. (I can go further and advocate exceptions for such true
errors, but that's a different story.) It is not just because of this
convention that the interface of SetFilePointer() is so complicated.
Thank you for sharing the interesting anecdote. However I still fail
to see your point there: we live in a world where different conventions
coexist, and the point I can take is that care should be taken when
mixing different conventions or crossing the convention boundaries.
It seems that every COM programmer should be aware of the convention
using S_OK and S_FALSE, and it is a very bad mistake to change S_FALSE
to FALSE or vice versa. Maybe the language can help, especially with
the scoped enum in C++0x for this particular example, but it's too
late and we already have what we have now.
--
Seungbeom Kim
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]