title: Are macros the only way to force inline
body: <p>I have a class member function which is the critical path in my application. It must be as fast as possible for my application to deliver the expected (read: rather the hoped) overall performance.</p>
  
  <p>The function is rather complex but have nearly identical sections repeated several times. Something like:</p>
  
  <pre><code>if (condition)
  {
      //... some code
  }
  if (another condition}
  {
      //... nearly identical code which may change condition
  }
  if (condition)
  {
      //... some code (same as above)
  }
  
  // and so on
  </code></pre>
  
  <p>In order to make the code easier to read, understand and maintain I like to break it down and use function calls instead. Like:</p>
  
  <pre><code>if (condition)
  {
      some_function(some_param);
  }
  if (another condition}
  {
      some_function(some_other_param);
  }
  if (condition)
  {
      some_function(some_param);
  }
  </code></pre>
  
  <p>I can't afford any overhead calling functions so I like to make sure that <code>some_function</code> is inlined - always.</p>
  
  <p>I searched SO and read several post discussing similar issues but not exactly the same. These post indicates that the only way are <code>macro</code>.</p>
  
  <p>I will hate to use <code>macros</code> but on the other hand I also hate the complexity of my current function. It is like choosing between two evils.</p>
  
  <p>Is it so? Are macros the only way to achieve this?</p>
  
  <p><b>Update</b></p>
  
  <p>I got a lot good feedback (thanks).</p>
  
  <p>Nearly all answers suggest that I shall not worry/care about forcing function calls to be inline as the compiler will do <i>the best</i> for me anyway.</p>
  
  <p>So I decided to go for it and make a test. I rewrote the code to use function calls whenever code snippets could be reused and ended up with a much more readable (and maintainable) version.</p>
  
  <p>Then I tested the new code and the old code with 100 test runs and calculated the performance as an average. In average the performance of the new version was ~1% (a little less .. 0.88%) lower than the old code. So there was a performance hit. On the other hand - the performance hit was not as high as I expected.</p>
  
  <p>My conclusion is that I prefer the new code as it is much easier to understand. This also means easier to maintain, debug and hand-over to others. Then I'll have to find the lost performance by a gain in some other code block.</p>
  
  <p>Oh, the last thing - which answer to accept? I really don't know. All answers have been helpful input. But only two answers actually address the original question. To me they seem equally good so I'll take the one posted first.</p>