On Thu, Jan 03, 2002 at 08:43:55AM -0800, Craig Dickson wrote:
| 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?
The point there was that it isn't a feature of the language.
| > 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;
Macros are type-safe to the extent that their usage corresponds with
their intent. The only problem with macros is that very little checks
them. Using macros in C/C++ starts to approach the way python objects
are used, however in python the types are checked at runtime.
| inlines can be members of a class or namespace, macros can't.
True.
| 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.
Right.
| > 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?
Not that I know of.
| There are probably other differences between the debug and non-debug
| builds. Optimizations, perhaps?
Possibly. When debugging is enabled, optimizations are disabled,
right?
| 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.
Wouldn't those bugs be less reproducible? The assignment was to
design and implement an interpreter for "VSL" (Very Small Language).
The language was very simple, but given my programming experience at
the time it was a significant project. (if I were to do it now I
would use regexes and a tool like lex/yacc and it would take very
little time) The bug was that a certain bit of malformed input would
crash the app (or make it misbehave, I'm not certain which) rather
than generate an error message.
| > 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.
I was putting 'inline' on the smaller functions, but I stopped doing
it when I heard of the problems some people have had with it, and when
I learned that it doesn't improve much (especially compared with the
time spent thinking about it and ensuring that it isn't the cause of a
bug).
-D
--
He who belongs to God hears what God says. The reason you do not hear
is that you do not belong to God.
John 8:47
