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

[crashfourit]

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 at reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-dev
>