[ros-dev] Re: [ros-svn] [gdalsnes]
18113:-reorderInsertXscendingOrder macro argument order and update uses
Alex Ionescu
ionucu at videotron.ca
Wed Sep 28 13:18:37 CEST 2005
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
More information about the Ros-dev
mailing list