Re: OT: Language War (Re: "C" Manual)
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
Reply to: