«

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?

--
Ian Collins

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.

KHD

On Thu, 2011-01-13, Ian Collins 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?

Reducing compile times (sometimes drastically).
Improving readability -- if a file starts with '#include <foolib.h>'
you expect it to use functionality from foolib.

Yet, I don't think automatic "weeding" is desireable. The list of
#includes is to some extent documentation, and should be maintained
by a real person, IMHO.

I personally do some manual weeding now and then but don't spend a
lot of time trying to get it exactly right.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

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.

--
Ian Collins

On Jan 13, 1: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.

I wouldn't be so sure. I've heard that judicious use of pImpl combined
with removing superfluous headers can dramatically reduce build times,
like on the order of 10x or more.

I've had some confirming anecdotal evidence as well while working on a
codebase of ~4000 cpp files.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 1/13/2011 3:11 PM, Ian Collins 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?
>

The commercial tool Coverity has a checker for some of that.
It does not reorganize to the optimum, but it will tell you when you
are including a header unnecessarily.

- --
Nelson Ferreira
Pubkey: http://triatlantico.org/njsf.asc
(9DFE 82A7 C689 BAEE EC25 A8E8 3C64 1789 7420 ED20)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0vas4ACgkQPGQXiXQg7SBEsACfbEQi9OIF/9wj0bVXmaAZS2lC
m+oAnihfzYga4tzvTtnt0zAR9GhX3Jf9
=7j9H
-----END PGP SIGNATURE-----

On 01/14/11 10:06 AM, Joshua Maurice wrote:
> On Jan 13, 1: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.
>
> I wouldn't be so sure. I've heard that judicious use of pImpl combined
> with removing superfluous headers can dramatically reduce build times,
> like on the order of 10x or more.
>
> I've had some confirming anecdotal evidence as well while working on a
> codebase of ~4000 cpp files.

I guess a lot depends on where you are starting from. If build time is
considered early enough in a project, it is less of an issue.

--
Ian Collins

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).

And, it turns out, that for C++ code scanning and tokenization can
be a substantial if not the lion's share of total compilation time.
Especially with "modern" code where the headers often comprise huge
portions of the code.

By the way, Walter Bright (as you know a genius compiler writer)
has IIRC talked discussed this a few times in this forum usually
in the context of a "true" modules system and the inadequacy of
pre-compiled headers.

KHD

On Thu, 2011-01-13, Ian Collins 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.

But eliminating dependency triggers is a way to reduce compile times!

If I edit foo.h, type "make" and a dozen files are recompiled even
though the change in foo.h cannot affect the twelve object files, that
time is wasted.

(Not that I think a tool is the answer; see elsewhere in the thread.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On 01/13/2011 03:47 PM, Keith H Duggar 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).

Using "#pragma once" as the first line of the header file solves this
problem, and is supported in nearly every modern version of GCC, Visual
Studio and any compiler that uses MCPP as its preprocessor.