Re: Excessive Inlining
* James Kanze:
On Mar 31, 4:03 pm, "Alf P. Steinbach" <a...@start.no> wrote:
* James Kanze:
On the other hand, most (but not all) compilers require the
definition of the function to be present in the compilation unit
in order to inline. Which, of course, introduces significant
compiler dependencies, and has a significant negative effect on
programmer productivity.
Does it?
Measurably.
General rule: "of course", "as we all know", and the like, most likely
mean "fishy statement ahead".
In this case, it means something that any programmer with
experience has run into. At least, if he's worked on programs
of any reasonable size.
I think that must be specific to the environment(s) you're used to,
and/or a statistical correlation between not-abiding-by-rules and low
quality code (which would not be surprising). I've seen the latter
effect, but not any problem from inlining per se. However, the few
sizeable C++ systems I've worked on have had far more serious problems,
obscuring any possible effect from inlining.
When you write "significant compiler dependencies" I think you mean
public module dependencies, i.e. undesirable public coupling, dragging
in headers that aren't really needed for the module's interface.
One way to deal with that is to focus on the undesirable coupling
instead of a language feature that one thinks is causing it.
Most coding guidelines I've seen ban inline functions
completely, for this reason.
No template programming, then...
Not at the application level, no.
ITYM that any template programming is by definition not part of the
application level. Then, not surprisingly, the application level turns
out to be a template free zone, except for use of (by definition)
library templates.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?