undefined | Better HN

0 pointsjacquesm8y ago0 comments

Presumably there is a #define I int floating around somewhere so that need not be the case (note the capital I inside the curly brace).

0 comments

dangerbird28y ago

the Big "I" is the type, which is a macro parameter. The variable name "i" is not a parameter. If There is another variable "i" in the scope, the loop variable will shadow it in the DO statement. Something like this

    float i = 10;
    DO({i+= 10;} 20);

will evaluate to this, modifying the "i" declared inside the macro

    float i_1 = 10;
    {I i_2=0,_n=(n);for(;i_2<_n;++i_2){i_2 += 10;}}

jacquesmOP8y ago

Hm, in the linked page there is a typedef long for I.

    typedef long I;

    #define DO(n,x) {I i=0,_n=(n);for(;i<_n;++i){x;}}

(I added a comma here after the }, 20 is the x parameters)

    DO({i+= 10;}, 20);

expands to:

    typedef long I;

    {I i=0,_n=({i+= 10;});for(;i<_n;++i){20;}};

The '20' presumably should have been some kind of function call or action to repeat and the 'n' should have been the count (the reverse from your example).

So that would make this:

    typedef long I;

    {I i=0,_n=(20);for(;i<_n;++i){ i+= 10; }};

You're still right that it will shadow any 'i' declared outside and so it won't work but it will not overwrite it as far as I can see. You'll just end up right where you started.

What I really don't get is if they're going to use _n for the count anyway why not count it down to 0, that way the whole 'i' could be avoided.

(you'd still have a problem with _n but that could be overcome with a convention, which of course someone will forget with some nasty bug as a result)

j / k navigate · click thread line to collapse