small #define and macro question

Thread Starter

Maen

Joined Sep 16, 2011
12
Hello,

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?
Rich (BB code):
#define SET_PORTXYZ(x) ((x) ? (PortXYZ->BSRR = 0xFF) : (PortXYZ->BSRR = 0xFF<<8))
rather than
Rich (BB code):
void setPortXYZ(int x)
{
  PortXYZ->BSRR = 0xFF << ((1-x)*8);
}
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:

Papabravo

Joined Feb 24, 2006
21,159
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
Rich (BB code):
#define ALINE  b + a*x
#define BLINE (b + a*x)
// Does this if statement evaluate the expression as TRUE or FALSE
    if(c*ALINE == c*BLINE)
    {  // True Part
    }
    else
    {  // False Part
    }
//  ?
The expression is FALSE!
 
Last edited:

codehead

Joined Nov 28, 2011
57
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?
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.
 

russ_hensel

Joined Jan 11, 2009
825
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.
 
Top