-2

Possible Duplicate:
Inline functions vs Preprocessor macros
what is concept of Inline function and how it is differ from macro? 

inline unsigned int getminutes( unsigned int seconds )
{
    return( seconds / 60 );
}

#define GetMinutes(seconds) (seconds) / (60)

To be honest I'd ask which one is faster, but I've seen so much on S.O that asking which one is better would grant me me knowledge. (Yes! I'm a knowledge hunter)

Community
  • 1
  • 1
Vinícius
  • 15,498
  • 3
  • 29
  • 53
  • 5
    Please *fully* parenthesize expression macros (not just the macro parameter). This kind of mistake is one reason you should probably tend toward inline functions... – Michael Burr Sep 26 '12 at 17:55
  • Why don't you learn to benchmark instead? – netcoder Sep 26 '12 at 17:55
  • @netcoder: Well, he did ask which is better and say that he *would* ask which is faster, but didn't. – Sion Sheevok Sep 26 '12 at 17:56
  • and http://stackoverflow.com/questions/6402613/, http://stackoverflow.com/questions/1137575/, http://stackoverflow.com/questions/4761504/, http://stackoverflow.com/questions/8221275/, http://stackoverflow.com/questions/3810221/, http://stackoverflow.com/questions/8712967/, http://stackoverflow.com/questions/4334041/, and many many more. – Mooing Duck Sep 26 '12 at 17:56
  • Another option to consider is `const unsigned minutes = seconds / 60;`. It is not that the factor `60` is hard to understand ("magic number") or likely to change during the lifetime of the program. – Bo Persson Sep 26 '12 at 18:20

4 Answers4

4

Never use a macro if you can use an inline function to achieve the same. The compiler is going to generate exactly the same code for both of the solutions you provided, assuming you are using a fairly decent one.

Of course there is no guarantee that inline functions will actually be inlined, but in these cases, if your compiler can't inline that function, then it's probably a really bad one.

Just don't use macros unless you really need to(header guards, do repetitive stuff, etc). Macros are evil in several ways, you can read a lot about that if you search for information online.

mfontanini
  • 21,410
  • 4
  • 65
  • 73
2

I guess the macro will be faster if you consider that inline is not guaranteed by the compiler to be used. If the function is not inlined, then you have the overhead of a function call.

The macro will be expanded in place by the preprocessor, so it's always going to be inline. The macro is also not type safe and has global scope.

Functions are preferred.

Tony The Lion
  • 61,704
  • 67
  • 242
  • 415
  • 1
    If the compiler is so bad that it cannot inline a one-liner, how do we know that it doesn't implement the divide as a call to `RTL_incredibly_slow_divide(seconds, 60)`? Then the macro will effectively not be inlined either. – Bo Persson Sep 26 '12 at 18:12
0

With a good optimizing compiler the performance will be identical. The difference is that the inline function is more or less a suggestion to the compiler. Although the compiler should in most cases honor the suggestion, the macro version will force the compiler to inline the code.

As an aside, your macro should be written ((seconds) / 60) to make sure the intended grouping is used in all cases.

HerrJoebob
  • 2,264
  • 16
  • 25
0

Unfortunately, which is faster is one of those cases where the only way to know is to profile. I suspect, however, that the result is the same in typical release build settings.

Which is better, however, I'd say the inline function. Easier to debug. Safer than a macro.

I avoid macros except where absolutely necessary. I think of them as compile-time find-and-replace. I consider find-and-replace to be extremely dangerous at worst. I actually wrote a post or two about why I dislike #define macros so intensely...

Another word of advice I run on: The compiler knows better than you. The macro will force inline, even if it's actually not good for performance. inline will suggest it as a candidate for inlining, but may not inline if it doesn't meet criteria to be inlined.

Sion Sheevok
  • 4,057
  • 2
  • 21
  • 37