28 Sep
2005
28 Sep
'05
11:18 a.m.
Gunnar Dalsnes wrote:
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.
Ge van Geldorp wrote:
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++.
From:
Gunnar Dalsnes
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: 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 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;
}
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. 2)Using gotos are much more ugly imo.
Oh, so goto's are acceptable if and only if you hide them out of sight? 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