Ge van Geldorp wrote:
From: Gunnar
Dalsnes
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.
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?
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
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.