28 Sep
2005
28 Sep
'05
8:02 p.m.
Gunnar Dalsnes wrote:
Ge van Geldorp wrote:
Yes. Hiding it _is_ the point.
You've just proven yourself what's wrong with flow control macros. Do
you really think that in the sorry state in which Win32K is, it really
needs macros to HIDE what's going on? When we can't even show a font
properly with -O2? When we still have random graphics corruption? When
we.. (I could go on for ages).
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. Readability is what its all about.
Readability != Hiding code.
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;".
"I"mo. Not the "o" of 15 other people. So don't force it.
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
Best regards,
Alex Ionescu
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.