dman wrote: > However the thing to remember about macros is that they are textual > substituation. It is effectively the same thing as writing the > assignment yourself.
So? You could say the same of C++ templates, but that doesn't mean they aren't useful. You can't even use the "code bloat" argument against templates if your alternative is to write out all the instances by hand; the result is the same, it just saves time and reduces errors to write it once instead of once per type. > inline functions are really no better than macros, and can even cause > bugs (though surely that's just a sign of a buggy compiler). I'm not that familiar with how inline is used in C, but in C++, it's silly to say that inlines are no better than macros. Inlines are type-safe, macros aren't; inlines can be members of a class or namespace, macros can't. And you're right that any bugs resulting from the "inline" keyword must result from bugs in the compiler, but that's an argument against using buggy compilers, not an argument against inlines. > For a particular school project (C++ required) the profs had a working > demo that we could run to verify our output (and clarify anything in > the specs). They compiled it without debug symbols so we couldn't > look at it in a debugger and reverse-engineer it. Their demo would > crash with certain malformed input. One of the profs tried to figure > it out, but once it was recompiled with debug symbols (which also > turns off inlining, for that compiler at least) the program worked > correctly. They had used inline functions extensively in their > code. Was this ever tracked down? There are probably other differences between the debug and non-debug builds. Optimizations, perhaps? Working in Win32 with Microsoft C++, I've several times had bugs that only happened in non-debug builds. It's never been because of inlines, though. Usually subtle timing issues, or a rogue pointer that in a debug build was pointing at something harmless. > There's no real point to an inline function, just make it a regular > function. The overhead of a function call isn't very big, especially > nowadays. The overhead is a lot less than it used to be (at least for the x86 family; I'm less familiar with others), but it's still non-zero, so it still matters in performance-critical code. I have always tended to inline trivial class/namespace members as a matter of habit, because in some cases the inlining actually results in smaller code than a regular function would (no parameter passing overhead, and optimizations can be applied to the inlined code as if it were part of the function that called it). As with performance, this isn't usually all that big a deal these days, but it certainly doesn't hurt. Craig