Re: Header File Clutter
On Jan 14, 4:40 pm, Keith H Duggar <dug...@alum.mit.edu> wrote:
On Jan 14, 4:41 am, James Kanze <james.ka...@gmail.com> wrote:
On Jan 13, 9:47 pm, Keith H Duggar <dug...@alum.mit.edu> wrote:
On Jan 13, 4:03 pm, Ian Collins <ian-n...@hotmail.com> wrote:
On 01/14/11 09:25 AM, Keith H Duggar wrote:
On Jan 13, 3:11 pm, Ian Collins<ian-n...@hotmail.com> wrote:
On 01/14/11 08:33 AM, Joe Hesse wrote:
When I write many X.h and X.cpp files and debug/modify
them, after a while they contain library or other header
files that may not be necessary. I realize that there
are #ifdef's that prevent a header file from being
included more than once so it doesn't hurt to put them
in more places than necessary.
My question is: Is there a tool to take a C++ program
that compiles and reorganize the header files so there
are no more #include<blah> than necessary?
While it is possible, what real benefits would such a tool bring?
I would have thought it obvious that it can significantly
reduce compile times and especially eliminate dependency
triggers.
Eliminate dependency triggers, yes but significantly reduce
compile times? Include guards take care of most waste
there.
Unfortunately they do not (unless you are talking about external
guards?). The reason is that due to the textual include mechanism
and C++ language rules, internal guards still require that the
entire contents of the header file and recursively on down must
be scanned and tokenized (but not parsed etc).
No they don't. Any decent compiler will note that the included
file had include guards, and not even open it when it is
included a second time. This has been standard practice since
the mid-1990's. (I'm pretty sure that g++ was the first to
introduce it.)
This above statement is simply false. I've come to realize that
when many a Mr. X in this forum writes "any decent" it actually
translates to "my fantasy".
My "any decent compiler" is admittedly a figure of speak. Most
compilers would be quite accurate, however.
I am afraid the devil is in the details for this particular C++
compilation aspect.
Agreed. Defining what is the same file is not trivial, and to
be frank, I don't know exactly what definition g++ (for example)
uses. But the example problematic cases don't generally show up
in actual practice.
When you actually start writing the compiler
reality lays waste to your fantasies. If you would review the
many many discussions /after/ the mid-1990's you would learn
the many reasons why you are wrong and why the problems are only
getting worse not better (as a result of changes in C++ usage as
well as proposed language changes):
Here is a recent article by Walter
http://www.drdobbs.com/blog/archives/2010/08/c_compilation_s.html
giving a short but accurate synopsis.
A not very accurate synopsis. G++ (and if I can trust my
measurements, Sun CC as well) don't reopen an include file
protected by include guards more than once, regardless of how
many times it has been included.
So (sadly for all of us C++ users) you are wrong; James' fantasy
compiler does not exist; Walter is right.
My "fantasy" compiler is called g++. The source code is
available, so you can even see how it does it.
--
James Kanze