Gunnar Dalsnes wrote:
Ge van Geldorp wrote:
From: Gunnar Dalsnes
And I think these macro's are a perfect example of Phillip's point. I have no idea how the flow of control is without looking at the macro definitions.
Sure you do, if you try _reeeealy_ hard;-P
No, really, I don't <<without looking at the macro definitions>>. RETURN sounds much like return, it is non-obvious that they're actually goto's to CLEANUP. Ofcourse, I figured it out when you committed that stuff 3 weeks ago, but when looking at it last night it was again non-obvious to me. On the other hand, I had no problem whatsoever figuring out the macro-free code that Nathan posted:
Yes, but how is this different from someone not knowing/understanding that a finally block is called when returning from a try block?
That's a compiler language feature. That's like saying that learning some 3rd party macro is equivalent to what operator new does in C++.
I may very well think the the finally block is only executed if i run at the end of the try block.
Someone that has learnt Win32 C/C++ programming and exception handling wouldn't think that.
But i _learned_ and figured out how it works. And now i _remeber_.
I also learnt and remember English. But I chose not to learn Zimbabwean.
But its not that same you say, because the macro _can_ be implemented by hardcoding, while try/finally cannot. Uhm, try/finally in ros IS macros;-P Noone said, "kjk, s*rew you and your seh macros." "This belongs in the compiler." "I refuse to learn how to use those ugly seh macros."
I think KJK has told me a million times how ugly PSEH is and how it should be in the compiler. But unlike other macros, we desperately need PSEH macros, we don't have a way around it. And their flow-control is as "hidden" as the seh intrinsics in compiler SEH.
BOOL NtFunc() { BOOL bResult; void *pPointer = NULL;
Lock();
if (Stuff) { bResult = FALSE; goto cleanup; } ....
bResult = TRUE;
cleanup: if (pPointer) free(pPointer); Unlock(stuff); DPRINT1("NtFunc returned %i\n", bResult); return bResult; }
2)Using gotos are much more ugly imo.
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.
I think it's a great way to do
S = Foo(); if (S) { S = Foo(); if (S) { S = Foo(); if (S) { S = Foo(); } else { goto cleanup; } } else { goto cleanup; } } else { goto cleanup; }
cleanup: HeapFree(...) return Status;
instead of having the cleanup code quadriplicated.
I didnt make those macros so i could type less. I made they so i can _read_ less. Thats the point. Readability. When looking at code i like to quickly spot the points of return. In complex code, and if it already have gotos, its confusing. Having a reserved word like RETURN is also nice for sytax highlightning (and its actually the same _word_ as normally used for return;-). Making up a mind about what the code does very quickly is nice, and with RETURN i can do that just as fast (faster) as with return.
Im sure all of you would like those macros if you didnt refuse to learn- and use them. But as long as you do you will off course hate them. I hate all the stuff i dont understand as well.
That's really a flawed statement. Learning and using these macros won't change their inner deficiencies as being flow control macros. Learning and using them will just propagate a frowned-upon programming practice. Your argument is much like saying "I'm sure if you all used uninitialized variables you'll like them".
G.
Best regards, Alex Ionescu