What is the difference between MACRO and FUNCTION?

Discussion in 'C Programming' started by Newbie_sw2003, Sep 10, 2003.

  1. Where should I use them?

    I am giving you my understandings. Please correct me if I am wrong:

    MACRO:
    e.g.:#define ref-name 99
    The code is substituted by the MACRO ref-name. So no overhead.
    Execution is faster. Where will it be stotred?(Is it in bss/stack/?)

    FUNCTION:
    There will be a overhead due to function arguments. (Aguments are
    stored in the stack)

    Where MACROs can not be used?
    =========================
    If the macro defination go like kind of x++ and y++. It's better to
    use functions and avoid macros. Use typedef instead of macros (while
    pointer declarations).

    Where FUNCTIONs can be used?
    ========================
    Anywhere. But RELATIVELY there will be a overhead and takes more CPU
    cycles to execute the same. If it's a macro, just simple substitution.

    Please throw some light on the above understandings of mine.
    -Newbie
     
    Newbie_sw2003, Sep 10, 2003
    #1
    1. Advertising

  2. Newbie_sw2003 <> scribbled the following:
    > Where should I use them?


    > I am giving you my understandings. Please correct me if I am wrong:


    > MACRO:
    > e.g.:#define ref-name 99
    > The code is substituted by the MACRO ref-name. So no overhead.


    Correct. The compiler is not even aware that there was a macro. All
    it sees is the substituted value.

    > Execution is faster. Where will it be stotred?(Is it in bss/stack/?)


    The C standard does not define "bss", "stack", or any other storage.
    It could be carved in stone if the implementation so wishes.

    > FUNCTION:
    > There will be a overhead due to function arguments. (Aguments are
    > stored in the stack)


    There will also be overhead because of the function itself. Calling
    a function is an operation that takes up time. Again, no specific
    storage is defined by the standard.

    > Where MACROs can not be used?
    > =========================
    > If the macro defination go like kind of x++ and y++. It's better to
    > use functions and avoid macros. Use typedef instead of macros (while
    > pointer declarations).


    Macros can't be pointed to either. You can give functions as
    parameters to other functions, but not macros.
    Also, macros can do things typedefs can't.

    > Where FUNCTIONs can be used?
    > ========================
    > Anywhere. But RELATIVELY there will be a overhead and takes more CPU
    > cycles to execute the same. If it's a macro, just simple substitution.


    Functions also have their own variable scope, so they have their own
    local variables. Functions also have a proper notion of arguments, while
    macros only use textual substitution.

    > Please throw some light on the above understandings of mine.
    > -Newbie


    --
    /-- Joona Palaste () ---------------------------\
    | Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
    | http://www.helsinki.fi/~palaste W++ B OP+ |
    \----------------------------------------- Finland rules! ------------/
    "Life without ostriches is like coffee with milk."
    - Mika P. Nieminen
     
    Joona I Palaste, Sep 10, 2003
    #2
    1. Advertising

  3. Newbie_sw2003

    Tom Zych Guest

    Joona I Palaste wrote:

    > The C standard does not define "bss", "stack", or any other storage.
    > It could be carved in stone if the implementation so wishes.


    Who know, maybe nanocomputers will someday store data by removing
    atoms of silicon from a surface...

    --
    Tom Zych
    This email address will expire at some point to thwart spammers.
    Permanent address: echo '' | rot13
     
    Tom Zych, Sep 10, 2003
    #3
  4. Newbie_sw2003

    Dan Pop Guest

    In <bjn0ht$e3d$> Joona I Palaste <> writes:

    >Newbie_sw2003 <> scribbled the following:
    >> Where should I use them?

    >
    >> I am giving you my understandings. Please correct me if I am wrong:

    >
    >> MACRO:
    >> e.g.:#define ref-name 99
    >> The code is substituted by the MACRO ref-name. So no overhead.

    >
    >Correct.


    ???

    >The compiler is not even aware that there was a macro.


    For the simple reason that there was no macro at all.

    >All it sees is the substituted value.


    No macro, no substitution. Only a syntax error requiring a diagnostic.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Sep 10, 2003
    #4
  5. Newbie_sw2003

    Tom Zych Guest

    Newbie_sw2003 wrote:

    > e.g.:#define ref-name 99


    '-' is not a legal character for C identifiers. Just A-Z a-z 0-9 and
    '_'.

    --
    Tom Zych
    This email address will expire at some point to thwart spammers.
    Permanent address: echo '' | rot13
     
    Tom Zych, Sep 10, 2003
    #5
  6. Dan Pop <> scribbled the following:
    > In <bjn0ht$e3d$> Joona I Palaste <> writes:


    >>Newbie_sw2003 <> scribbled the following:
    >>> Where should I use them?

    >>
    >>> I am giving you my understandings. Please correct me if I am wrong:

    >>
    >>> MACRO:
    >>> e.g.:#define ref-name 99
    >>> The code is substituted by the MACRO ref-name. So no overhead.

    >>
    >>Correct.


    > ???


    >>The compiler is not even aware that there was a macro.


    > For the simple reason that there was no macro at all.


    >>All it sees is the substituted value.


    > No macro, no substitution. Only a syntax error requiring a diagnostic.


    There I was, looking for some sense in Dan's reply, when it struck me.
    The hyphen (-) is an illegal character in macro names, therefore Dan, in
    his usual cryptic form, is right. The code would have to read:
    #define ref_name 99

    --
    /-- Joona Palaste () ---------------------------\
    | Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
    | http://www.helsinki.fi/~palaste W++ B OP+ |
    \----------------------------------------- Finland rules! ------------/
    "No, Maggie, not Aztec, Olmec! Ol-mec!"
    - Lisa Simpson
     
    Joona I Palaste, Sep 10, 2003
    #6
  7. Newbie_sw2003

    Dan Pop Guest

    In <bjniq9$pcu$> Joona I Palaste <> writes:

    >Dan Pop <> scribbled the following:
    >> In <bjn0ht$e3d$> Joona I Palaste <> writes:

    >
    >>>Newbie_sw2003 <> scribbled the following:
    >>>> Where should I use them?
    >>>
    >>>> I am giving you my understandings. Please correct me if I am wrong:
    >>>
    >>>> MACRO:
    >>>> e.g.:#define ref-name 99
    >>>> The code is substituted by the MACRO ref-name. So no overhead.
    >>>
    >>>Correct.

    >
    >> ???

    >
    >>>The compiler is not even aware that there was a macro.

    >
    >> For the simple reason that there was no macro at all.

    >
    >>>All it sees is the substituted value.

    >
    >> No macro, no substitution. Only a syntax error requiring a diagnostic.

    >
    >There I was, looking for some sense in Dan's reply, when it struck me.
    >The hyphen (-) is an illegal character in macro names, therefore Dan, in
    >his usual cryptic form, is right. The code would have to read:
    >#define ref_name 99


    The harder you work to find a mistake, the less is the likelihood of ever
    repeating it ;-)

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Sep 10, 2003
    #7
  8. Newbie_sw2003

    Ed Morton Guest

    On 9/10/2003 6:05 AM, Joona I Palaste wrote:
    > Newbie_sw2003 <> scribbled the following:
    >
    >>Where should I use them?

    >
    >
    >>I am giving you my understandings. Please correct me if I am wrong:

    >
    >
    >>MACRO:
    >>e.g.:#define ref-name 99
    >>The code is substituted by the MACRO ref-name. So no overhead.

    >
    >
    > Correct. The compiler is not even aware that there was a macro. All
    > it sees is the substituted value.
    >
    >
    >>Execution is faster. Where will it be stotred?(Is it in bss/stack/?)

    >
    >
    > The C standard does not define "bss", "stack", or any other storage.
    > It could be carved in stone if the implementation so wishes.


    If "it" is the macro definition (as opposed to the invocation), it isn't stored.
    The preprocessor expands the macro definition in-line so to the compiler it's
    just more text within the function or wherever you happen to have placed the
    macro invocation.

    >>FUNCTION:
    >>There will be a overhead due to function arguments. (Aguments are
    >>stored in the stack)

    >
    >
    > There will also be overhead because of the function itself. Calling
    > a function is an operation that takes up time. Again, no specific
    > storage is defined by the standard.
    >
    >
    >>Where MACROs can not be used?
    >>=========================
    >>If the macro defination go like kind of x++ and y++. It's better to
    >>use functions and avoid macros. Use typedef instead of macros (while
    >>pointer declarations).

    >
    >
    > Macros can't be pointed to either. You can give functions as
    > parameters to other functions, but not macros.
    > Also, macros can do things typedefs can't.
    >
    >
    >>Where FUNCTIONs can be used?
    >>========================
    >>Anywhere. But RELATIVELY there will be a overhead and takes more CPU
    >>cycles to execute the same. If it's a macro, just simple substitution.

    >
    >
    > Functions also have their own variable scope, so they have their own
    > local variables. Functions also have a proper notion of arguments, while
    > macros only use textual substitution.


    I know you know this, but for the OP: macros CAN have their own scope too, if
    you define them as such, e.g.:

    #define PRTHELLO() do { \
    char *_x = "hello"; \
    puts(_x); \
    } while (0)

    Notes:

    1) The underscore in front of the variable name - since macros are expanded
    in-line, it's good to have a naming convention for variables declared within the
    macro that at least attempts to separate them from the variables declared in a
    calling function.

    2) The backslashes at the end of each line - unlike a function, a macro
    definition ends at the end of the line, so to let you split your text over
    multiple lines for ease of reading, you need to escape the end of lines.

    3) The { ... } - this creates the scope for local variable declarations AND
    bug-proofs the code so that if someone wrote a multi-statement macro and then
    put it inside an "if" with no braces, the whole body would be considered as one
    block. e.g. if I define 2 macros:

    #define DOAB() \
    a(); \
    b()

    #define DOXY() { \
    x(); \
    y(); \
    }

    if (condition1)
    DOAB();

    if (condition2)
    DOXY();

    then this will expand to:

    if (condition1)
    a();
    b(); /* NOTE: b() is no longer within the "if"
    * and so will be executed unconditionally!
    */

    if (condition2)
    {
    x();
    y();
    };

    so if condition1 is fales, b() will still get executed.

    4) The do ... while(0) - this forces callers of the macro to put a semi-colon at
    the end. In the example above I had

    if (condition2)
    DOXYZ();

    but that trailing semicolon is actually unnecessary as you can see from the
    expanded version above and can in fact cause problems. By changing the
    definition to:

    #define DOXY() do { \
    x(); \
    y(); \
    } while(0)

    this expands to:

    if (condition2)
    do {
    x();
    y();
    } while(0);

    which does now require that trailing semi-colon. One advantage of requiring the
    semicolon on the invocation is that you could in future replace the text in the
    macro definition with a function call and not have to worry about potentially
    introducing errors in the code of callers who had/hadn't been relying on not
    needing that semicolon. For more info on "do ... while(0)", see the comp.lang.c
    FAQ http://www.eskimo.com/~scs/C-faq/q10.4.html

    5) The macro name is all upper-case - that's a pretty normal convention for
    user-defined macros whereas function names are typically a mix of upper/lower case

    6) Macros should be kept small - a rough rule of thumb for macros vs functions
    is to only use macros if the code size is small (less than, say, 20 or so lines)
    and you can't afford the function call real-time overhead.

    Ed.

    >>Please throw some light on the above understandings of mine.
    >>-Newbie

    >
    >
     
    Ed Morton, Sep 11, 2003
    #8
    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. jakk
    Replies:
    4
    Views:
    12,246
  2. Aakash Jain
    Replies:
    2
    Views:
    13,425
    David Harmon
    Apr 13, 2004
  3. lasek

    Difference between Macro and Function...

    lasek, Oct 21, 2004, in forum: C Programming
    Replies:
    8
    Views:
    988
    Robert Wessel
    Oct 22, 2004
  4. Patrick Kowalzick
    Replies:
    5
    Views:
    477
    Patrick Kowalzick
    Mar 14, 2006
  5. MAx
    Replies:
    21
    Views:
    1,586
    Army1987
    Sep 21, 2007
Loading...

Share This Page