Alf said:
* Luke Meyers:
On the contrary.
The Microsoft style
Beg pardon? I don't know what "the Microsoft style" is, and I'm
curious why you assume I would. I'll proceed assuming you meant the
practice of minimizing header includes, preferring to place those
includes as locally as possible -- that is, in the implementation
files.
makes a mess of file dependencies,
As I see it, it reduces dependencies. If Bar uses Baz, and Foo uses
Bar but not Baz, under your scheme Foo must recompile anyway
(needlessly) whenever Baz.h changes. If the include of Baz.h is in
Bar.cpp, instead of Bar.h, this recompilation dependency goes away. If
your point of view is really contrary to this, could you please explain
your reasoning?
introduces #include statement order depends, with associated problems,
I fail to see the relationship here. Well-designed headers should not
have order dependencies, regardless of what other headers they do or
don't include. Order dependencies commonly arise from the practice of
relying on some other header to include the header you're using, rather
than just including it yourself. Such side-effects are not part of a
class's interface, can change without notice, and should not be relied
upon.
and often
results in one big mother-of-all include file to ensure that all that's
required is there, in the right order: imposing on all of the code that
which caused the problems in the first place.
I agree that this may occur, given the premise of #include order
dependencies. I disagree that the practice I recommend leads to such
order dependencies.
If header inclusion impact negatively on build times, then those headers
are badly designed.
In what sense? The recompilation dependency introduced by
unnecessarily moving #includes to headers, per your recommendation, is
sufficient to drastically reduce average build speed.
First, try to fix them, i.e. add proper include
guards and perhaps (conditional on the compiler) #pragma once.
Include guards are a remedial and obvious step -- omission of them will
cause all sorts of problems in any case. My recommendation assumes
that such basic steps are universally taken -- if they're not, then the
answer is to adopt them, not to move #include directives around.
If that
doesn't help, consider whether you're accessing headers off a network
drive and have a really old, less than smart compiler. One fix is then
to upgrade the compiler. Another to move the headers to local storage.
A third, to use local storage wrapper headers.
These are non-sequiturs -- while such steps may improve build speeds
for some people in some situations, they have nothing to do with the
aspect of #include structure under discussion. Please let's get back
to the point at hand; explain, if you would, your reasoning from the
point where our opinions diverged.
Luke
) "A header file