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

[Gunnar Dalsnes]

Alex Ionescu wrote:
> Gunnar Dalsnes wrote:
> 
>> If Alex doesnt like it ill revert it in the files that he "own", but 
>> this "i own the code" stuff has gone too far.
> 
> 
> It's not about "owning". Call it "maintaining" if you want, like Steven 
> said. And it's not "Alex" doesn't like it, it's erm, Alex, Steven, 
> Thomas, Casper, Hartmut and probably others.
> I'll go in more detail on 
> the technical reason why, at least for me, the macros are unacceptable.  
> (Other then the fact that macros in the programming world are considered 
> to be as bad as goto.) Here's something I can do that your macros remove:
> 
> HeadList = &Foo.Flink
> DPRINT1("List head at: %p\n", HeadList);
> Entry = HeadList->Flink;
> DPRINT1("Entry at: %p\n", Entry);
> while (Entry != HeadList)
> {
>       DPRINT1("Getting object\n");
>       Object = CONTAINING_RECORD(Entry, OBJECT, Link);
>       DPRINT1("Got the object: %p\n", Object);
>            <.... do stuff>
> 
>       DPRINT1("About to remove entry from list\n");
>       RemoveEntryList(&Object->Link);
> 
>      DPRINT1("Entry removed, moving to: %p\n", Entry->Flink);
>      Entry = Entry->Flink;
> }

If you come across a crash during an enum you just temporarily change 
the code to hunt the bug, just like normal bug hunting. Some of the list 
enums i changed were on this form...

for (HeadList = &Foo.Flink; Entry != HeadList; Entry = Entry->Flink)
{
    Object = CONTAINING_RECORD(Entry, OBJECT, Link);
    Object->stuff
}

...and if you had to "debug" it like you showed youd had to edit the 
code just as well. But for normal not-in-process-of-being-debugged-code 
i think the above code sux (even without the dprints).

> 
> In the current state that ReactOS + the kernel + debugging facilities 
> are, that is sometimes the only way to find out what's crashing during a 
> list .
> 
>>
>> Any person can see that those macros produce much cleaner code, and 
>> without any measureable performance loss. And the stuff with "macros 
>> screw my debugging", all list manipulation functions are already macros.
> 
> 
> No they're not. They're inlined functions. And they do 
> insertion/removal, not parsing lists. See above why parsing should be 
> expanded.

Yeah, i see now they are inlined in latest DDKs...

>