Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 6 of 6

Thread: Pre-processor math question

  1. #1

    Pre-processor math question

    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.

  2. #2
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,670
    Quote Originally Posted by neroroxxx View Post
    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.

  3. #3
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,493
    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

  4. #4
    Senior Member
    Join Date
    Feb 2015
    Location
    Finland
    Posts
    183
    Quote Originally Posted by neroroxxx View Post
    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); .

    Quote Originally Posted by neroroxxx View Post
    Would it instead be better to do this:
    No, but not worse, either.

    Quote Originally Posted by neroroxxx View Post
    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.

  5. #5
    Thank you all for the info! i'll check out those links has been taken!

  6. #6
    Senior Member
    Join Date
    Feb 2015
    Location
    Finland
    Posts
    183
    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!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •