On Jul 6, 5:59 pm, "Alf P. Steinbach" <al...@start.no wrote:
* James Kanze:
On Jul 6, 5:20 pm, joseph cook <joec...@gmail. comwrote:
>Of course, current best practice is not to use inline at all, so
the problem doesn't occur.
Why do you say this?
Because it increases coupling.
In-lining functions in a header file can be critical for
performance reasons.
Really? I never use it, and I've not had any performance
problems.
If you do actually have a performance problem, and the profiler
shows that it is in a tight loop where you do call a non-inlined
function, then inlining it is a simple and cheap optimization.
Using inline before the profiler says you have to, however, is
premature optimization.
Inlining things in headers is a technique that saves
programmer's time both for initial development, for use of the
header, and for maintainance (which reportedly constitutes
about 80% of all programming work).
I don't know where you get that from. It is a nightmare with
regards to maintenance, easily doubling the effort required.
(To begin with, if you don't know if the function is inlined or
not, you don't even know in which file to look for it. And of
course, if you have to modify it, then all of the client code
needs to be recompiled.)
I agree that doing inlining for reasons of performance would
be premature optimization, of the kind that might even
influence runtime in a negative way, and bring in unwanted
coupling and have other undesirable effect.
However, used as a means for programmer productivity, not as
premature optimization, its effect on coupling is generally
negligible.
If it's used in a template, it's negligible, because the
template code has to be included anyway (at least with most
current compilers). If it's not a template, however, the effect
in practice can be quite high.
Obviously, it's only one factor: you can write impossible to
maintain code without a single inline function, and carefully
used, you can minimize the impact. But globally, all of the
coding guidelines I've seen for application code forbid inline
functions---and usually also require user defined
implementations of the functions the compiler will generate by
default as well, since the compiler generated versions are
inline. (The rules for library code are somewhat different,
since you often have to guess where the client code's
bottlenecks might occur.)
It can even reduce the number of files that must be opened and
read during a build. I think the programmer who's afraid of
using std::vector just because it's perceived as a large
header & requires full def of element type, is seriously
misguided.
That, certainly. But std::vector is (hopefully) stable code,
which isn't evolving while you're working. So you won't end up
having to recompile everything because there was a small
correction in the implementation somewhere. (If you upgrade
your compiler, of course, you'll get a new version of
std::vector. But if you upgrade your compiler, you have to
recompile everything anyway, since all of the object files
depend in some way on the compiler. On the other hand, you
shouldn't be upgrading the compiler very often---maybe once
every two or three years, at the most.)
--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34