Pre-processor math question

neroroxxx

Well-known member
Hi all, I'm wondering if preprocessors do math or they just paste whats defined.

In this code:

Code:
#define DELAY_ITERATIONS 5

#define DELAY_VALUE (500/DELAY_ITERATIONS) // (500/5)

delay(DELAY_VALUE);

I'm assuming delay(DELAY_VALUE); will compile "delay((500/5));" which means that the math is being done everytime i use DELAY_VALUE, is this the case or does the compiler figure that DELAY_VALUE never changes so it does the math and assigns it 100 instead so the math doesn't have to be done everytime it's used?

Would it instead be better to do this:

Code:
#define DELAY_ITERATIONS 5

const uint16_t delayValue = (500/DELAY_ITERATIONS);

delay(delayValue);

In the second example delayValue will always be 100 so there's no extra math but is that a more "optimal" way to code something like this?

For my purposes that extra math doesn't hurt at all however curiousity took over and I wanna get in the habit of coding in the most optimal way i can not just the way that works.
 
Hi all, I'm wondering if preprocessors do math or they just paste whats defined.

In this code:

Code:
#define DELAY_ITERATIONS 5

#define DELAY_VALUE (500/DELAY_ITERATIONS) // (500/5)

delay(DELAY_VALUE);

I'm assuming delay(DELAY_VALUE); will compile "delay((500/5));" which means that the math is being done everytime i use DELAY_VALUE, is this the case or does the compiler figure that DELAY_VALUE never changes so it does the math and assigns it 100 instead so the math doesn't have to be done everytime it's used?

Would it instead be better to do this:

Code:
#define DELAY_ITERATIONS 5

const uint16_t delayValue = (500/DELAY_ITERATIONS);

delay(delayValue);

In the second example delayValue will always be 100 so there's no extra math but is that a more "optimal" way to code something like this?

For my purposes that extra math doesn't hurt at all however curiousity took over and I wanna get in the habit of coding in the most optimal way i can not just the way that works.

The preprocessor is just a textual substitution. When it sees 'DELAY_VALUE' it will substitute '(500/DELAY_ITERATIONS)' which in turn causes DELAY_ITERATIONS to be expanded. The expansion would be '(500/5)'.

The compiler proper will see (500/5) and fold it directly to 100.
 
you can see the output after the preprocessor stage with gcc -E file.c
i think the compiler will do 500/5 at compile time
 
Hi all, I'm wondering if preprocessors do math or they just paste whats defined.
Preprocessor only does math in #if clauses, but the compiler does integer arithmetic on literals at compile time. (For floating-point math, it depends on options used, and whether the expression has a precise result expressible in the floating-point format used.)

This means that for all intents and purposes, delay(DELAY_VALUE); generates the exact same machine code as delay((500/5)); and delay(100); .

Would it instead be better to do this:
No, but not worse, either.

For my purposes that extra math doesn't hurt at all however curiousity took over and I wanna get in the habit of coding in the most optimal way i can not just the way that works.
You are falling into a trap called premature optimization: you are worried about getting the tiny little details right, when it is the large-scale concepts, algorithms and such, that actually matter.

Instead of code level optimization, learn algorithm analysis, and about things like linked lists, various trees, binary heaps, disjoint sets, and algorithms that sort and merge them. The more you learn, the bigger your toolbox is, and the more efficient your implementations can be.

Code-level optimization is like practicing your hammering. Thing is, when you only use a hammer, all problems look like nails. Yet, we have (the analogues of) screws, adhesives, nuts and bolts, and so on; each with their own strengths and weaknesses.
 
You might find Mark Allen Weiss's Data Structures and Algorithm Analysis (either second edition in C, or third edition in C++) interesting and useful. You can find the second edition online if you cannot find a physical copy (it's from 1997).

I'm not saying it is the best one or the most well known, I'm only saying that I found it really interesting and useful when I first read it in, oh, '99 or thereabouts. I thought it was quite clear and easy to read, but it made a huge positive impact on the efficiency of my code. Like you, I want my programs to be robust and efficient -- I've been told I concentrate on it way too much!
 
Back
Top