Re: Eliminating nested functions

[Bean]

Hi,

Right, we can wrap the local variables in void* and pass them in a
custom pointer, but I still think it's advantageous to put them in a
structure rather than use multiple parameters:

1, We can still use nested function. Sometimes it may seem tedious to
use external function for simple callback function. IMO, nested
function is not that bad, we just have to use it safely.

2. It's extensible. For example, we may need to add new information
for the hook function (such as adding modification time for dir hook).
With the structure pointer, we just need to add a new field, old code
that doesn' t use this information doesn't need to change. With
parameters, we need to change the definition of all callback function,
and the numerous __attribute__ ((unused)) is not pretty either.

On Sun, Apr 19, 2009 at 10:51 PM, Vladimir Serbinenko <address@hidden> wrote:
> In my opinion a far better way would be to add an additional void * argument
> which is passed unchanged to the hook. Like:
>
> struct local
> {
>    ...
> };
>
> main_func ()
> {
> struct local locvars;
>
> grub_*_iterate (arg1,arg2,arg3, &locvars);
> }
>
> hook (arg1, arg2, arg3, voidparg)
> {
> struct local *locvars = (struct local *) voidparg;
>
> }
>
> On Sun, Apr 19, 2009 at 4:29 PM, Pavel Roskin <address@hidden> wrote:
>>
>> Quoting Bean <address@hidden>:
>>
>>> Yeah, I agree with you. The conversion will take some effort, but it
>>> could payoff in the long run. Perhaps we can achieve this in two
>>> steps:
>>>
>>> 1, Change nested function definition to accept only one parameter. For
>>> function with multiple parameters, place them in a structure and pass
>>> the pointer. This would eliminate NESTED_FUNC_ATTR, as the regparm
>>> issue won't occur in function with only one parameter.
>>>
>>> 2. Eliminate nested function. This would be easier after step 1. As we
>>> now pass parameters in a structure, we can append extra variables at
>>> the end, and cast it to the required type. Inside the callback
>>> function, we cast it back to use the extra fields.
>>
>> That's an excellent plan!  Thank you!
>>
>> Considering the amount of changes, it may be a good idea to use the git
>> mirror with stgit, so that several patches can be made and everything is
>> well tested together before applying.
>>
>> --
>> Regards,
>> Pavel Roskin
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> address@hidden
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>



-- 
Bean