Re: inline request and compiler rejection
On Mar 21, 1:39 am, Jeff Schwab <j...@schwabcenter.com> wrote:
James Kanze wrote:
On Mar 20, 4:55 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
James Kanze wrote:
On Mar 19, 11:40 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
James Kanze wrote:
Inlining increases coupling.
Not, it doesn't, except in an extremely shallow sense.
I'm not sure what you mean by "shallow". It increases
compile time coupling significantly, which is extremely
important in anything except trivially small applications.
In the first place, that's not "coupling" in any meaningful sense.
It's coupling in the most classical sense.
"Coupling," in the "classical" sense, means that changes to
one portion of a code base require changes elsewhere.
Coupling means that changes in one place affect (many) other
places. This is the meaning the word has always had, and the
meaning with which it is almost universally used. If you want
to restrict its meaning to something else, fine. Just don't be
surprised if no one understands you.
Requiring recompilation, within an application, is only a
trivial form of coupling, and in this enables the compiler to
have significantly more information as it compiles each
translation unit.
I'm not sure I understand that sentence. If what you're trying
to say is that compilation dependencies are not as serious a
form of coupling as source code dependencies, fine. We agree on
that. That doesn't mean that you can neglect compilation
dependencies. They tend to chain: in one real project, we found
that before using the compilation firewall idiom, source codes
of around a thousand lines resulted in the compiler seeing
between 500 thousand and 2 million lines after preprocessing.
Use of the compilation firewall brought that figure down to
around 20 thousand. That had two major impacts: compile times
dropped drastically (that was on an older machine, but even
today, reading 2 million lines over the LAN takes time), and
significantly less files needed to be recompiled after a small
change in the implementation details of the class.
In the second place, as I already posted, I have not seen a
prohibitive effect on build times. The projects I work on
are not "trivially small."
If you're working on libraries, you won't see them. Your
users will. (If you're using dynamically loaded objects, it
may mean the difference between having to relink and
recompile, and not.)
I work mainly on commercial applications. With all due
respect, you don't know what you're talking about.
It's the client code which ends up paying for your extra
includes, not the library itself.
[...]
And if you change the contract, you have to at least look at
every place the function is used. A lot more than just one
or two places.
The places it is used are additional to the places in which
you declare it, not instead of.
Yes, but it does mean that one or two places more or less
doesn't make a difference.
Yes, it does. Most application-internal functions are called
in only a few places.
It occured to me after posting that you seem to be confusing two
issues. The fact that a function is inline doesn't mean that
you don't need both a declaration and a definition. In order
for the definition to serve as the declaration, it has to be in
the class. Do that, and you quickly end up with the unreadable
mess we know from Java. It's a nice feature for demo programs,
but once the class has more than three or four functions, and
the functions have more than two or three lines, the results are
completely unreadable.
That's why the desicion to change the signature usually rests in
other hands than the desicion to change the implementation, and
why it is important that the implementation and the signature
reside in different files.
That is complete nonsense.
No, it's good software engineering.
To make sure that every function's interface and
implementation are maintained by separate people? Rubbish.
To have a different procedure for modifying the interface than
for modifying the implementation is essential. In large
projects, it will almost always be a case of different people;
in small projects, it may be the same person wearing a different
hat. But the impact of changing an interface is significantly
different than that of changing an implementation.
Moreover, separating the definition from the prototype has
a staggering syntactic overhead in C++, particularly for
member functions and templates.
It could be simpler, but I've never found it to be a
particular problem. And I don't know how you can maintain
the public interface and the implementation in two separate
files otherwise. (Of course, a good tool set helps here;
you don't actually write the boilerplate yourself, the
machine does it for you.)
As always, you are entitled to your opinion. I'm not sure why
you have taken it as your personal responsibility to chastise
me every time I express an opinion you do not care for.
There are matters of taste, and there are matters of basic
software engineering. I tend to jump on anyone who recommends
bad engineering.
The fact that I prefer to inline more functions than you do
does not justify your claim of "bad engineering." This
brow-beating and insulting of people with whom you disagree is
petty and unbecoming.
It's not a question of more or less. Inline functions increase
coupling, and cause maintenance problems. Good software
engineering avoids them except in special cases.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34