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.