[ros-dev] Re: [ros-svn] [gdalsnes] 18113:-reorderInsertXscendingOrder macro argument order and update uses

[Alex Ionescu]

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