Macro redefinition

Discussion in 'C Programming' started by Tor Rustad, Aug 31, 2007.

  1. Tor Rustad

    Tor Rustad Guest

    I'm implementing a parser, where there is a lot of different data
    elements defined. Now instead of hand-coding X defines, and the massive
    number of lines needed for table initialization, I decided to generate
    this source instead.


    So, I basically used this trick:

    void gen_source_function(FILE *out)
    {
    #define EXPAND_DEF(num, name) generate_source_1(out, num, #name)
    #include "iso8583_defs"

    #define EXPAND_DEF(num, name) generate_source_2(out, num, #name)
    #include "iso8583_defs"

    }

    where the "iso8583_defs" file, did contain a lot of lines like this:

    EXPAND_DEF(1, FIELD_NAME);
    EXPAND_DEF(2, ANOTHER_FIELD_NAME);


    My question is simply, is the above C code allowed?


    --
    Tor <torust [at] online [dot] no>
    Tor Rustad, Aug 31, 2007
    #1
    1. Advertising

  2. Tor Rustad

    Ben Pfaff Guest

    Tor Rustad <> writes:

    > void gen_source_function(FILE *out)
    > {
    > #define EXPAND_DEF(num, name) generate_source_1(out, num, #name)
    > #include "iso8583_defs"
    >
    > #define EXPAND_DEF(num, name) generate_source_2(out, num, #name)
    > #include "iso8583_defs"
    >
    > }
    >
    > where the "iso8583_defs" file, did contain a lot of lines like this:
    >
    > EXPAND_DEF(1, FIELD_NAME);
    > EXPAND_DEF(2, ANOTHER_FIELD_NAME);
    >
    >
    > My question is simply, is the above C code allowed?


    Sure. Lots of code uses this trick to avoid redundancy.

    If you don't like the idea of using an include file for this, you
    can also use a macro:

    void gen_source_function(FILE *out)
    {
    #define ISO8583_DEFS \
    EXPAND_DEF(1, FIELD_NAME); \
    EXPAND_DEF(2, ANOTHER_FIELD_NAME);

    #define EXPAND_DEF(num, name) generate_source_1(out, num, #name)
    ISO8583_DEFS

    #define EXPAND_DEF(num, name) generate_source_2(out, num, #name)
    ISO8583_DEFS
    }

    I think it's a toss-up which is better. Neither is pretty, both
    are functional.
    --
    char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
    ={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
    =b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
    2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}
    Ben Pfaff, Aug 31, 2007
    #2
    1. Advertising

  3. Tor Rustad

    Dave Hansen Guest

    On Aug 31, 11:04 am, Tor Rustad <> wrote:
    > I'm implementing a parser, where there is a lot of different data
    > elements defined. Now instead of hand-coding X defines, and the massive
    > number of lines needed for table initialization, I decided to generate
    > this source instead.
    >
    > So, I basically used this trick:
    >
    > void gen_source_function(FILE *out)
    > {
    > #define EXPAND_DEF(num, name) generate_source_1(out, num, #name)
    > #include "iso8583_defs"
    >
    > #define EXPAND_DEF(num, name) generate_source_2(out, num, #name)
    > #include "iso8583_defs"
    >
    > }
    >
    > where the "iso8583_defs" file, did contain a lot of lines like this:
    >
    > EXPAND_DEF(1, FIELD_NAME);
    > EXPAND_DEF(2, ANOTHER_FIELD_NAME);
    >
    > My question is simply, is the above C code allowed?


    It's a pretty common idiom in the code I work with. One caveat: don't
    forget to #undef EXPAND_DEF before redefining it.

    Regards,

    -=Dave
    Dave Hansen, Aug 31, 2007
    #3
  4. Tor Rustad

    Tor Rustad Guest

    Ben Pfaff wrote:
    > Tor Rustad <> writes:
    >
    >> void gen_source_function(FILE *out)
    >> {
    >> #define EXPAND_DEF(num, name) generate_source_1(out, num, #name)
    >> #include "iso8583_defs"
    >>
    >> #define EXPAND_DEF(num, name) generate_source_2(out, num, #name)
    >> #include "iso8583_defs"
    >>
    >> }
    >>
    >> where the "iso8583_defs" file, did contain a lot of lines like this:
    >>
    >> EXPAND_DEF(1, FIELD_NAME);
    >> EXPAND_DEF(2, ANOTHER_FIELD_NAME);
    >>
    >>
    >> My question is simply, is the above C code allowed?

    >
    > Sure. Lots of code uses this trick to avoid redundancy.


    Yup, that's the idea.

    > If you don't like the idea of using an include file for this, you
    > can also use a macro:
    >
    > void gen_source_function(FILE *out)
    > {
    > #define ISO8583_DEFS \
    > EXPAND_DEF(1, FIELD_NAME); \
    > EXPAND_DEF(2, ANOTHER_FIELD_NAME);
    >
    > #define EXPAND_DEF(num, name) generate_source_1(out, num, #name)
    > ISO8583_DEFS
    >
    > #define EXPAND_DEF(num, name) generate_source_2(out, num, #name)
    > ISO8583_DEFS
    > }


    Interesting, I haven't seen this solution before.

    However, there is a translation limit of "509 characters in a logical
    source line", and isn't logical source lines made up after line-splicing
    your ISO8583_DEFS above?

    --
    Tor <torust [at] online [dot] no>
    Tor Rustad, Aug 31, 2007
    #4
  5. Tor Rustad

    Tor Rustad Guest

    Dave Hansen wrote:

    <snip>

    >> My question is simply, is the above C code allowed?

    >
    > It's a pretty common idiom in the code I work with. One caveat: don't
    > forget to #undef EXPAND_DEF before redefining it.


    Is really the #undef needed in this case? This is a function-like macro,
    and the re-definition had identical argument list.

    --
    Tor <torust [at] online [dot] no>
    Tor Rustad, Aug 31, 2007
    #5
  6. Tor Rustad <> writes:
    > Dave Hansen wrote:
    >
    > <snip>
    >
    >>> My question is simply, is the above C code allowed?

    >> It's a pretty common idiom in the code I work with. One caveat:
    >> don't
    >> forget to #undef EXPAND_DEF before redefining it.

    >
    > Is really the #undef needed in this case? This is a function-like
    > macro, and the re-definition had identical argument list.


    C99 6.10.3p2:

    An identifier currently defined as an object-like macro shall not
    be redefined by another #define preprocessing directive unless the
    second definition is an object-like macro definition and the two
    replacement lists are identical. Likewise, an identifier currently
    defined as a function-like macro shall not be redefined by another
    #define preprocessing directive unless the second definition is a
    function-like macro definition that has the same number and
    spelling of parameters, and the two replacement lists are
    identical.

    This is a constraint.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Aug 31, 2007
    #6
  7. Tor Rustad

    Ben Pfaff Guest

    Tor Rustad <> writes:

    > However, there is a translation limit of "509 characters in a logical
    > source line", and isn't logical source lines made up after
    > line-splicing your ISO8583_DEFS above?


    Interesting point. I've not run into an implementation (yet)
    that has such a stringent limit. I notice that C99 expanded the
    limit to 4095 characters.
    --
    int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz.\
    \n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
    );while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p\
    );}return 0;}
    Ben Pfaff, Aug 31, 2007
    #7
  8. In article <>,
    Tor Rustad <> wrote:

    >Keith, I don't get your point. Doesn't the
    >
    >"unless the second definition is a function-like macro definition that
    >has the same number and spelling of parameters, and the two replacement
    >lists are identical"
    >
    >apply?


    The replacement lists were different. One had generate_source_1,
    the other generate_source_2. There wouldn't have been much point
    if they were the same.

    -- Richard
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
    Richard Tobin, Aug 31, 2007
    #8
  9. Tor Rustad

    Tor Rustad Guest

    Keith Thompson wrote:
    > Tor Rustad <> writes:
    >> Dave Hansen wrote:
    >>
    >> <snip>
    >>
    >>>> My question is simply, is the above C code allowed?
    >>> It's a pretty common idiom in the code I work with. One caveat:
    >>> don't
    >>> forget to #undef EXPAND_DEF before redefining it.

    >> Is really the #undef needed in this case? This is a function-like
    >> macro, and the re-definition had identical argument list.

    >
    > C99 6.10.3p2:
    >
    > An identifier currently defined as an object-like macro shall not
    > be redefined by another #define preprocessing directive unless the
    > second definition is an object-like macro definition and the two
    > replacement lists are identical. Likewise, an identifier currently
    > defined as a function-like macro shall not be redefined by another
    > #define preprocessing directive unless the second definition is a
    > function-like macro definition that has the same number and
    > spelling of parameters, and the two replacement lists are
    > identical.
    >
    > This is a constraint.


    Keith, I don't get your point. Doesn't the

    "unless the second definition is a function-like macro definition that
    has the same number and spelling of parameters, and the two replacement
    lists are identical"

    apply?

    --
    Tor <torust [at] online [dot] no>
    Tor Rustad, Aug 31, 2007
    #9
  10. Tor Rustad

    Tor Rustad Guest

    Ben Pfaff wrote:
    > Tor Rustad <> writes:
    >
    >> However, there is a translation limit of "509 characters in a logical
    >> source line", and isn't logical source lines made up after
    >> line-splicing your ISO8583_DEFS above?

    >
    > Interesting point. I've not run into an implementation (yet)
    > that has such a stringent limit. I notice that C99 expanded the
    > limit to 4095 characters.


    In my case, there will be _at least_ 128 lines to splice, each line on
    average ca. 50 characters long, in total 6400 characters minimum.

    --
    Tor <torust [at] online [dot] no>
    Tor Rustad, Aug 31, 2007
    #10
  11. Tor Rustad

    Ben Pfaff Guest

    Tor Rustad <> writes:
    >> Tor Rustad <> writes:
    >>> Dave Hansen wrote:
    >>>>> My question is simply, is the above C code allowed?
    >>>> It's a pretty common idiom in the code I work with. One caveat:
    >>>> don't
    >>>> forget to #undef EXPAND_DEF before redefining it.
    >>> Is really the #undef needed in this case? This is a function-like
    >>> macro, and the re-definition had identical argument list.

    > Doesn't the
    >
    > "unless the second definition is a function-like macro definition that
    > has the same number and spelling of parameters, and the two
    > replacement lists are identical"
    >
    > apply?


    Your replacement lists are different: the first has
    generate_source_1, the second has generate_source_2.
    --
    "It would be a much better example of undefined behavior
    if the behavior were undefined."
    --Michael Rubenstein
    Ben Pfaff, Aug 31, 2007
    #11
  12. Tor Rustad

    Ben Pfaff Guest

    Tor Rustad <> writes:

    > Ben Pfaff wrote:
    >> Tor Rustad <> writes:
    >>
    >>> However, there is a translation limit of "509 characters in a logical
    >>> source line", and isn't logical source lines made up after
    >>> line-splicing your ISO8583_DEFS above?

    >>
    >> Interesting point. I've not run into an implementation (yet)
    >> that has such a stringent limit. I notice that C99 expanded the
    >> limit to 4095 characters.

    >
    > In my case, there will be _at least_ 128 lines to splice, each line on
    > average ca. 50 characters long, in total 6400 characters minimum.


    Then you'd definitely be better off an include file.
    --
    "I should killfile you where you stand, worthless human." --Kaz
    Ben Pfaff, Aug 31, 2007
    #12
  13. Tor Rustad

    Ian Collins Guest

    Tor Rustad wrote:
    > I'm implementing a parser, where there is a lot of different data
    > elements defined. Now instead of hand-coding X defines, and the massive
    > number of lines needed for table initialization, I decided to generate
    > this source instead.
    >
    >
    > So, I basically used this trick:
    >
    > void gen_source_function(FILE *out)
    > {
    > #define EXPAND_DEF(num, name) generate_source_1(out, num, #name)
    > #include "iso8583_defs"
    >
    > #define EXPAND_DEF(num, name) generate_source_2(out, num, #name)
    > #include "iso8583_defs"
    >
    > }
    >
    > where the "iso8583_defs" file, did contain a lot of lines like this:
    >
    > EXPAND_DEF(1, FIELD_NAME);
    > EXPAND_DEF(2, ANOTHER_FIELD_NAME);
    >
    > My question is simply, is the above C code allowed?
    >

    With the require #unded as explained else thread, it is quite common.

    One project I worked on used it extensively, but with hind site, we
    found the code hard to maintain, so we dropped the technique and used
    code generation from XML instead.

    --
    Ian Collins.
    Ian Collins, Aug 31, 2007
    #13
  14. Tor Rustad

    Tor Rustad Guest

    Ben Pfaff wrote:
    > Tor Rustad <> writes:
    >>> Tor Rustad <> writes:
    >>>> Dave Hansen wrote:
    >>>>>> My question is simply, is the above C code allowed?
    >>>>> It's a pretty common idiom in the code I work with. One caveat:
    >>>>> don't
    >>>>> forget to #undef EXPAND_DEF before redefining it.
    >>>> Is really the #undef needed in this case? This is a function-like
    >>>> macro, and the re-definition had identical argument list.

    >> Doesn't the
    >>
    >> "unless the second definition is a function-like macro definition that
    >> has the same number and spelling of parameters, and the two
    >> replacement lists are identical"
    >>
    >> apply?

    >
    > Your replacement lists are different: the first has
    > generate_source_1, the second has generate_source_2.


    Ahh.. I see and learned something new! :)

    --
    Tor <torust [at] online [dot] no>
    Tor Rustad, Aug 31, 2007
    #14
  15. Tor Rustad

    Tor Rustad Guest

    Ian Collins wrote:
    > Tor Rustad wrote:
    >> I'm implementing a parser, where there is a lot of different data
    >> elements defined. Now instead of hand-coding X defines, and the massive
    >> number of lines needed for table initialization, I decided to generate
    >> this source instead.


    [...]

    > One project I worked on used it extensively, but with hind site, we
    > found the code hard to maintain, so we dropped the technique and used
    > code generation from XML instead.


    For now, I only need to parse messages of the ISO 8583 1993 standard,
    one future complication could be to handle the 1987 and 2001 standards
    as well. Even so, I can't see how the parser code could become hard to
    maintain. The source generator program is tiny, it's input table is "small".

    In a more complex case, XML could perhaps give something, but in this
    case I would rather write an ASN.1 specification and have the C code
    generated by an ASN.1 compiler.


    Generally, I'm *sick* of all that XML wasting HD space and network
    bandwidth these days... *yuck*


    --
    Tor <torust [at] online [dot] no>
    Tor Rustad, Sep 1, 2007
    #15
  16. Tor Rustad

    Ian Collins Guest

    Tor Rustad wrote:
    > Ian Collins wrote:
    >> Tor Rustad wrote:
    >>> I'm implementing a parser, where there is a lot of different data
    >>> elements defined. Now instead of hand-coding X defines, and the massive
    >>> number of lines needed for table initialization, I decided to generate
    >>> this source instead.

    >
    > [...]
    >
    >> One project I worked on used it extensively, but with hind site, we
    >> found the code hard to maintain, so we dropped the technique and used
    >> code generation from XML instead.

    >
    > For now, I only need to parse messages of the ISO 8583 1993 standard,
    > one future complication could be to handle the 1987 and 2001 standards
    > as well. Even so, I can't see how the parser code could become hard to
    > maintain. The source generator program is tiny, it's input table is
    > "small".
    >

    It was as much a case of people's dislike of the "macro magic" as much
    as anything else. We also ended up with several product using various
    part of the database, so a more modular approach was required.

    > In a more complex case, XML could perhaps give something, but in this
    > case I would rather write an ASN.1 specification and have the C code
    > generated by an ASN.1 compiler.
    >

    The team also disliked ASN.1! There are more tools to parse, merge and
    fiddle about with XML documents.
    >
    > Generally, I'm *sick* of all that XML wasting HD space and network
    > bandwidth these days... *yuck*
    >

    Me too, I'm down to my last Terabyte!

    --
    Ian Collins.
    Ian Collins, Sep 1, 2007
    #16
  17. Tor Rustad

    Thad Smith Guest

    Ben Pfaff wrote:
    > Tor Rustad <> writes:
    >
    >> void gen_source_function(FILE *out)
    >> {
    >> #define EXPAND_DEF(num, name) generate_source_1(out, num, #name)
    >> #include "iso8583_defs"
    >>
    >> #define EXPAND_DEF(num, name) generate_source_2(out, num, #name)
    >> #include "iso8583_defs"
    >>
    >> }
    >>
    >> where the "iso8583_defs" file, did contain a lot of lines like this:
    >>
    >> EXPAND_DEF(1, FIELD_NAME);
    >> EXPAND_DEF(2, ANOTHER_FIELD_NAME);
    >>
    >>
    >> My question is simply, is the above C code allowed?

    >
    > Sure. Lots of code uses this trick to avoid redundancy.
    >
    > If you don't like the idea of using an include file for this, you
    > can also use a macro:
    >
    > void gen_source_function(FILE *out)
    > {
    > #define ISO8583_DEFS \
    > EXPAND_DEF(1, FIELD_NAME); \
    > EXPAND_DEF(2, ANOTHER_FIELD_NAME);
    >
    > #define EXPAND_DEF(num, name) generate_source_1(out, num, #name)
    > ISO8583_DEFS
    >
    > #define EXPAND_DEF(num, name) generate_source_2(out, num, #name)
    > ISO8583_DEFS
    > }
    >
    > I think it's a toss-up which is better. Neither is pretty, both
    > are functional.


    Here's another way to do it. Include the macro file, as first proposed,
    but make it the same as the including file! Here's an example:

    //* incex.c - Show example of self inclusion */
    #ifdef M1
    M1(Sharon)
    M1(Robert)
    M1(Nancy)
    #else

    #include <stdio.h>

    #define M1(n) n,
    enum names {
    #include "incex.c" /* include self for M1 list */
    N_NAMES
    };
    #undef M1

    #define M1(n) #n,
    const char *const namestring[] = {
    #include "incex.c" /* include self for M1 list */
    ""
    };
    #undef M1

    int main (void) {
    enum names i;

    for (i=Robert; i <= Nancy; i++) {
    printf ("%d: %s\n", i, namestring);
    }
    return 0;
    }
    #endif
    ----------------
    Pretty sleazy, but it only has a single list and is self contained! You
    can even extend it to multiple macro lists.


    --
    Thad
    Thad Smith, Sep 1, 2007
    #17
  18. Tor Rustad

    Gene Guest

    On Aug 31, 4:06 pm, Ian Collins <> wrote:
    > Tor Rustad wrote:
    > > I'm implementing a parser, where there is a lot of different data
    > > elements defined. Now instead of hand-coding X defines, and the massive
    > > number of lines needed for table initialization, I decided to generate
    > > this source instead.

    >
    > > So, I basically used this trick:

    >
    > > void gen_source_function(FILE *out)
    > > {
    > > #define EXPAND_DEF(num, name) generate_source_1(out, num, #name)
    > > #include "iso8583_defs"

    >
    > > #define EXPAND_DEF(num, name) generate_source_2(out, num, #name)
    > > #include "iso8583_defs"

    >
    > > }

    >
    > > where the "iso8583_defs" file, did contain a lot of lines like this:

    >
    > > EXPAND_DEF(1, FIELD_NAME);
    > > EXPAND_DEF(2, ANOTHER_FIELD_NAME);

    >
    > > My question is simply, is the above C code allowed?

    >
    > With the require #unded as explained else thread, it is quite common.
    >
    > One project I worked on used it extensively, but with hind site, we
    > found the code hard to maintain, so we dropped the technique and used
    > code generation from XML instead.
    >


    Yes. I've had a similar experience. "Preprocessor abuse" has often
    led me to a place where something that needed to be done was beyond
    the cpp to handle. Using python or perl or similar to generate code
    is better in the long run. Most recently, I've used TXL (txl.ca) as a
    very robust and maintainable way to (among other things) implement a
    language extension inside an established language.
    Gene, Sep 1, 2007
    #18
  19. "Tor Rustad" <> wrote in message
    news:...
    > Keith Thompson wrote:
    >> Tor Rustad <> writes:
    >>> Dave Hansen wrote:
    >>>>> My question is simply, is the above C code allowed?
    >>>>
    >>>> It's a pretty common idiom in the code I work with. One caveat:
    >>>> don't
    >>>> forget to #undef EXPAND_DEF before redefining it.
    >>>
    >>> Is really the #undef needed in this case? This is a function-like
    >>> macro, and the re-definition had identical argument list.

    >>
    >> C99 6.10.3p2:
    >>
    >> An identifier currently defined as an object-like macro shall not
    >> be redefined by another #define preprocessing directive unless
    >> the second definition is an object-like macro definition and the
    >> two replacement lists are identical. Likewise, an identifier
    >> currently defined as a function-like macro shall not be redefined
    >> by another #define preprocessing directive unless the second
    >> definition is a function-like macro definition that has the same
    >> number and spelling of parameters, and the two replacement
    >> lists are identical.
    >>
    >> This is a constraint.

    >
    > Keith, I don't get your point. Doesn't the
    >
    > "unless the second definition is a function-like macro definition
    > that has the same number and spelling of parameters, and the
    > two replacement lists are identical"
    >
    > apply?


    Benign redefinition only exists when you do the same thing twice. For
    instance, this is okay:

    #define FOO 1
    #define FOO 1

    This is not:

    #define FOO 1
    #define FOO 2

    In the latter case, you need to #undef FOO before you redefine it.

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking


    --
    Posted via a free Usenet account from http://www.teranews.com
    Stephen Sprunk, Sep 1, 2007
    #19
  20. Tor Rustad

    Tor Rustad Guest

    Thad Smith wrote:

    <snip>


    > Here's another way to do it. Include the macro file, as first proposed,
    > but make it the same as the including file! Here's an example:
    >
    > //* incex.c - Show example of self inclusion */
    > #ifdef M1
    > M1(Sharon)
    > M1(Robert)
    > M1(Nancy)
    > #else
    >
    > #include <stdio.h>
    >
    > #define M1(n) n,
    > enum names {
    > #include "incex.c" /* include self for M1 list */
    > N_NAMES
    > };
    > #undef M1
    >
    > #define M1(n) #n,
    > const char *const namestring[] = {
    > #include "incex.c" /* include self for M1 list */
    > ""
    > };
    > #undef M1
    >
    > int main (void) {
    > enum names i;
    >
    > for (i=Robert; i <= Nancy; i++) {
    > printf ("%d: %s\n", i, namestring);
    > }
    > return 0;
    > }
    > #endif
    > ----------------
    > Pretty sleazy, but it only has a single list and is self contained! You
    > can even extend it to multiple macro lists.


    Ahh.. that was a clever solution! One pass, no need for a
    generator program.


    --
    Tor <torust [at] online [dot] no>
    Tor Rustad, Sep 1, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dead RAM
    Replies:
    20
    Views:
    1,094
    John Harrison
    Jul 14, 2004
  2. D Senthil Kumar

    macro name from macro?

    D Senthil Kumar, Sep 20, 2003, in forum: C Programming
    Replies:
    1
    Views:
    565
    Jack Klein
    Sep 21, 2003
  3. sounak

    to get macro name from macro value

    sounak, Nov 22, 2005, in forum: C Programming
    Replies:
    17
    Views:
    486
    Mark McIntyre
    Nov 22, 2005
  4. Patrick Kowalzick
    Replies:
    5
    Views:
    459
    Patrick Kowalzick
    Mar 14, 2006
  5. Mike Manilone

    macro inside macro

    Mike Manilone, Oct 3, 2011, in forum: C Programming
    Replies:
    8
    Views:
    440
    Mike Manilone
    Oct 6, 2011
Loading...

Share This Page