28 Sep
2005
28 Sep
'05
7:40 p.m.
Ge van Geldorp wrote:
Yes. Hiding it _is_ the point. Readability is what its all about. Not
the code behind the names. I dont care whats behind a name/operator
(compiler builtin, assembly, function call, macro etc.) as long as it do
what i want and have a (in this case) _uniqueue_ name that describes
what it does. Imo, "RETURN(45)" look better than "ret = 45; goto
cleanup;".
BTW: As for thinking about what low level code lies behind a name i
remeber the old(?) "i dont want to use while(TRUE) because it produce
shitty asm, so i use for(;;) instead". I don't know if anyone thinks
that anymore, but those who did needs a good spanking;-P
From: Gunnar
Dalsnes
The definition of your RETURN():
#define RETURN(value) { _ret_ = value; goto _cleanup_; }
which seems to set a retval and then does a goto to the end. So, again,
"ugly code" (your words, not mine) is acceptable if you hide it out of
sight? Oh, so goto's are acceptable if and only if
you hide them
out of sight?
No, i think gotos are ok internally but i dont like them for return.
First set a retval and then goto to the end. ugh...ly. BTW, the following code which looks perfectly
acceptable won't compile
correctly with your definition:
if (somecondition)
RETURN(errorcode);
else
do_something_else();
I admit this is a bit contrived example, you don't need the "else".
Finally some constructive critisism;-P
It can be solved like this:
#define RETURN(value) do {_ret_ = value; goto _cleanup_; }while(0)
Gé van Geldorp.
G.