4 ms·
That's an obvious question. A lot of macros should be functions. The most common case I'm aware of are functions like toupper(), islower(), ispunct(), etc. th
by maxlybbert 11y ago
That's an obvious question. A lot of macros should be functions.
The most common case I'm aware of are functions like toupper(), islower(), ispunct(), etc. that the C Standard allows to be macros for performance (the actual work in the function is testing or setting a single bit, and the overhead of a function call really matters in that case).
Inline functions would have the same performance, and you can get a pointer to them without doing the #undef rigamarole you see when a macro definition might muck things up.
- maximilianburke 11y agoInline functions aren't guaranteed to be inlined. There are compiler specifics that add stronger hints to the optimizer to inline but behavior isn't always consistent from one compiler to the next. The only portable way to force something to be inlined is to use a macro.
- chrisseaton 11y agoWhy is it essential that anything is inlined? Maybe if the compiler isn't inlining it had a good reason for that? Maybe it has some understanding of the trade off between specialisation and code size for these particular functions which you don't.
- m_mueller 11y agoBecause compilers need to work for any program, thus tend to the best common denominator, while you, the programmer, can design something for a particular use case. In this case, hot loops - at best a compiler could know about the runtime intensity by using a runtime profile and then deciding that, yes, in this case it's actually best to inline something. But having a compile -> link -> run (profiled) -> compile -> link workflow is much too bothersome and slow (so most don't do this) and it's much more manageable to sit down and turn on your brain when programming. This stance of "no premature optimisation" has gone overboard IMO.
- maxlybbert 11y agoIf the compiler doesn't inline something, you generally have no way of knowing if the reason was had good or bad.
- maximilianburke 11y agoIn most cases I would wager I have a better idea of where I want the optimizations to be applied in code than the compiler does. Macros, unlike inline functions, will always give you the result you are looking for. You don't have to worry about things like regressed performance because a new compiler versions has tweaked inlining heuristics. The use of "inline" is diminished in much real world C++ too. Because it's used liberally in user code and added implicitly to member functions defined in a class definition there already is much code that is inline-worthy. There is no way in C++ to say "I explicitly want THIS code to be inlined HERE", unless you use a macro. In theory you can get benefits out of using PGO but PGO is also non-standard, not available on all compilers, and a pain to setup. Inline functions will also never be able to replace the diagnostics available with the preprocessor; being able to extract the line and file for things like assertions is something you can't do with inline functions. Inline functions have their use, but so do preprocessor pseudo-function macros, and saying that there isn't a valid use for these macros is claptrap that I'd attribute to someone who hasn't shipped performance sensitive code in C or C++ before.
- chrisseaton 11y ago> saying that there isn't a valid use for these macros Nobody in this thread has said that.
- maxlybbert 11y agoI recognize that there is some use for macros, but the valid cases have been getting smaller over time.