small #define and macro question

Discussion in 'Programmer's Corner' started by Maen, Nov 24, 2011.

  1. Maen

    Thread Starter Member

    Sep 16, 2011

    I've got 2 small questions:

    1 : is there a difference between #define xyz 0x0FA and #define xyz (0x0FA)? (programming in C)

    2 : is there an advantage to using macros instead of creating a function?
    Code ( (Unknown Language)):
    1. #define SET_PORTXYZ(x) ((x) ? (PortXYZ->BSRR = 0xFF) : (PortXYZ->BSRR = 0xFF<<8))
    rather than
    Code ( (Unknown Language)):
    1. void setPortXYZ(int x)
    2. {
    3.   PortXYZ->BSRR = 0xFF << ((1-x)*8);
    4. }
    PortXYZ is in push-pull mode and BSRR is his Set/Reset register (8 MSB are reset and 8 LSB are set)

    Edit : Nevermind the 2nd part, found the answer (less CPU operations, but larger compiled code and longer compilation time).
    Last edited: Nov 24, 2011
  2. Papabravo


    Feb 24, 2006
    In the specific case of defining a macro to substitute a constant for a symbol, there is probably no point in enclosing the constant in parentheses. If on the other hand you write a macro to substitute an EXPRESSION for a symbol, then the parentheses are used to control the order of evaluation which may be altered by the context in which the macro is placed.

    I hope that is clear.

    For Example
    Code ( (Unknown Language)):
    2. #define ALINE  b + a*x
    3. #define BLINE (b + a*x)
    4. // Does this if statement evaluate the expression as TRUE or FALSE
    5.     if(c*ALINE == c*BLINE)
    6.     {  // True Part
    7.     }
    8.     else
    9.     {  // False Part
    10.     }
    11. //  ?
    The expression is FALSE!
    Last edited: Nov 24, 2011
    Maen likes this.
  3. codehead

    Active Member

    Nov 28, 2011
    Papabravo gave an example of why it's good to place the macro definition in parentheses, but there are other less-obvious reasons that you will eventually get snagged by if you program long enough, including when you nest macros (define something, then use that in another macro, which in turn gets used in your program). Just do it by habit, or you'll forget once when you need it and regret it.

    Macros are a bit ugly. I use them most often just for control of the compiling process. Using functions instead is less efficient, but since macros are usually simple, you can substitute inline functions that are efficient and safer (though unless they are very simple, your compiler may or may not honor making it inline—"inline" is a request, not a command). Inlines also have the advantage that you can step through the code, unlike macros.

    Functional macros and inlines can have huge performance benefits in time-critical applications. For instance, in a real-time digital signal processing app, let's say you need a second-order lowpass filter function; an audio application would use a filter like this for many purposes. Just writing out the code every time it appeared in the program would be prone to error, and if you later found a mistake you'd have to repair every instance of the code, so it makes sense to make it a function. However, such filters might be executed over and over in your program, to the point that the overhead of calling it each time eats up too many cycles.

    That is, functional macros and inlines are only only good for short bit of code. So, reproducing them in a (non-inline) function means that the calls overhead will be relatively high. With some code that matter a lot, but for simple stuff you'll never know it—it's you call.
  4. russ_hensel

    AAC Fanatic!

    Jan 11, 2009
    remember that #define process is basically text replacement prior to compilation. for example if you write #define 2 * 3 the 2 * 3 will go right into the code. an optimizing compiler will probable later change it into a 6, but that is not part of the #define processing.
  5. t06afre

    AAC Fanatic!

    May 11, 2009
    The define is more a tool for making the code more readable. Then used correct that is