On 10/31/2016 11:01 AM, Halil Pasic wrote: > > > On 10/31/2016 06:32 PM, Jianjun Duan wrote: >>>>> I think this got overly complicated. Here is a little patch on >>>>>>>>>> top of your stuff which gets rid of 15 lines and IMHO simplifies >>>>>>>>>> things quite a bit. What do you think? >>>>>>>>>> >>>>>>>>>> It is based on/inspired by Dave's proposal with the dummy stuff. >>>>>>>>>> >>>>>>>>>> Did not address the typos though. >>>>>> It is unlikely the definition of QTAILQ will change, so hard-coded >>>>>> value probably was the most simple. Now that we want to address the >>>>>> potential changes, I think my code will deal with future changes better. >>>> >>>> Please elaborate in what way does your version deal better with future >>>> changes? IMHO the version with my patch applied covers all the corners >>>> your original code covers but it is without any doubt more concise and >>>> in my opinion also more straight-forward. >> I don't use the internals of head and entry structures if there are >> access macro around. Also I didn't use pointer type cast. I don't think >> pointer cast is more straightforward. > > > Internals is quite relative since the stuff is part of the header > and there is no indication that it's not part of the API. About > pointer type casts I do not understand what you mean by that: > my understanding is that we both do casts to a pointer type. And > I do think it is more straightforward than defining a macro for the > offset for each link-pointer and then basically play the field_at_offset > game twice: once to pin point the struct holding all the links, and > once again to pinpoint the individual links. > It is more concise but not more straightforward for me.
> As you see I do not believe you that your version is more robust. > If you want to convince me _give me a remotely reasonable patch_ which > beaks my version but not yours. > > The straight-forwardness is probably a matter of taste, and that's > why I used IMHO. I'm not sure if I understood you correctly, do > you think that the current version of the code is more readable > that what I have proposed? If you do, I doubt there is a rational > way to settle this taste dispute. If the majority of the people > says your approach is more straight-forward then I apologize. > I agree it is a matter of taste. With current code both versions will not break. But if somebody changes the name of the var you directly accessed, your code will break. Of course I don't expect somebody to just do that. It is indeed in the header file and we expect people to change all at once if any change is done. I used this argument for hard encoding and it is not taken. Thanks, Jianjun > Cheers, > Halil >
