Ben Bacarisse said:
What benefit do these macros provide? You don't show them and I can't
guess.
They just provide a way of putting the words true or false within the
expression for the benefit of a casual human* debugger.
#define istrue(arg) (arg)
#define isfalse(arg) !(arg)
(It just saves the guy from having to think ... "hmmm, is true expressed as
a zero or non-zero value in this language?")
It seems odd to me to have a convention of zero to represent successful
completion, but to then use the value as false:
# This logic does not work in C, because success is false
if thisfunctionsucceeds() then
# blah blah blah
else
print "Damn! It's fucked."
# Note that our error handler is nicely positioned as a footnote
# below the main body of the the code
endif
That doesn't work in C, which means that to a human* reading the code, the
our error handler is now interrupting the flow as the program is read from
top down.
if thisfunctionfails() {
/* The error handler is in right in your face at the top of the code */
printf("Damn! It's fucked")
} else {
/* blah blah blah */
}
In assembly language we use a goto, but some programmers do not like these.
# Although assembly language also uses the same convention as C, the
# one line goto, and the lack of braces, makes the jump to the error
# handler unobtrusive
call ourfunction
jnz errorhandler # We use a goto here
# blah blah blah
Trying a similar trick in C gives us
if thisfunctionfails() {
goto errorhandler; /* It still looks messy */
} else {
/* blah blah blah */
}
Or we can have a really horrible construct:
if thisfunctionfails() { goto errorhandler; } else {
blah blah blah
}
Note that blah blah blah is based on success, but the if statement above was
testing for failure! Yuck !
* Although I am human, I don't alway appear to be.
Mark.
