Hi, I'm new here, if y'all don't mind I'll throw my thoughts in. I tend to do soemthing like this:
int foo(void){ int ret;
if (stuf){ ret = FALSE; goto error; }; error: /* Error clean up code */
done: return (ret); };
I think that too many marcos can clutter up code. How ever, the marcos can be useful from keeping one from repeating the same task again and again, but one has to name them so other people can tell what they do.
Alex Ionescu wrote:
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 _______________________________________________ Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev