«

Are there any C tools that can find redundant #includes in a project,
so as to shorten compile time? Of course, eliminating single
#includes by hand and determining if the recompile fails is one
option, though that is an extremely manual and time-intensive
approach. Thanks,
--
Benjamin

Benjamin Rutt <brutt+> wrote in
news::

> Are there any C tools that can find redundant #includes in a project,
> so as to shorten compile time? Of course, eliminating single
> #includes by hand and determining if the recompile fails is one
> option, though that is an extremely manual and time-intensive
> approach. Thanks,

This trick will eliminate including the same file multiple times per
compile:

/* foo.h
*/
#ifndef FOO_H_INCLUDED
#define FOO_H_INCLUDED

/* foo.h file contents
*

#endif /* FOO_H_INCLUDED */

--
- Mark ->
--

"Mark A. Odell" <> writes:

> This trick will eliminate including the same file multiple times per
> compile:
>
> /* foo.h
> */
> #ifndef FOO_H_INCLUDED
> #define FOO_H_INCLUDED
>
> /* foo.h file contents
> *
>
> #endif /* FOO_H_INCLUDED */

Thanks, I'm sorry, I knew of that trick actually, and I've rarely seen
a header file without it...I guess I misstated my question. I was
actually talking about #includeing files that you don't need at all,
not even once, so my using 'redundant' was incorrect. I should have
asked:

How do you find which header files aren't used at all by a single
compilation unit, and can safely be deleted from a the .c file?
--
Benjamin

Benjamin Rutt wrote:

> How do you find which header files aren't used at all by a single
> compilation unit, and can safely be deleted from a the .c file?

I believe this falls under the topic of "lint," such as declaring unused
variables, code blocks that do nothing (ie "if (0 == 1) {[...]}", etc...),
redundant stuff ("a = 1; a = 5"), and all the other junk that accumulates
as projects evolve.

I would use a lint checker for that.

I have used the Gimpel lint checker (www.gimpel.com) quite successfully,
I'm sure there are others including free ones.

--
gabriel

Mark A. Odell wrote:

> Benjamin Rutt <brutt+> wrote in
> news::
>
>
>>Are there any C tools that can find redundant #includes in a project,
>>so as to shorten compile time? Of course, eliminating single
>>#includes by hand and determining if the recompile fails is one
>>option, though that is an extremely manual and time-intensive
>>approach. Thanks,
>
>
> This trick will eliminate including the same file multiple times per
> compile:
>
> /* foo.h
> */
> #ifndef FOO_H_INCLUDED
> #define FOO_H_INCLUDED
>
> /* foo.h file contents
> *
>
> #endif /* FOO_H_INCLUDED */
>

The file opening time may be reduced by using:
#ifndef FOO_H_INCLUDED
#include "foo.h"
#endif

Finding and opening a file is one of the major items
for compilation times. Also, in Mark's version, the
compiler must scan all the code looking for the
#endif, which takes time.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

Thomas Matthews <> wrote in
news:tKyUb.19100$. com:

>> This trick will eliminate including the same file multiple times per
>> compile:
>>
>> /* foo.h
>> */
>> #ifndef FOO_H_INCLUDED
>> #define FOO_H_INCLUDED
>>
>> /* foo.h file contents
>> *
>>
>> #endif /* FOO_H_INCLUDED */
>>
>
> The file opening time may be reduced by using:
> #ifndef FOO_H_INCLUDED
> #include "foo.h"
> #endif
>
> Finding and opening a file is one of the major items
> for compilation times. Also, in Mark's version, the
> compiler must scan all the code looking for the
> #endif, which takes time.

Doesn't this approach become cumbersome and error prone with many source
files and many header files? The standard way I mentioned means that the
user of the header file can blissly include the header file without fear
of multiple definition warnings.

--
- Mark ->
--

On Thu, 05 Feb 2004 11:49:31 -0500, Benjamin Rutt
<brutt+> wrote in comp.lang.c:

> Are there any C tools that can find redundant #includes in a project,
> so as to shorten compile time? Of course, eliminating single
> #includes by hand and determining if the recompile fails is one
> option, though that is an extremely manual and time-intensive
> approach. Thanks,

PC-Lint. http://www.gimpel.com.

Worth every penny, once you get the configuration files set up for
your code.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

Thomas Matthews wrote:

> The file opening time may be reduced by using:
>
> #ifndef FOO_H_INCLUDED
> #include "foo.h"
> #endif
>
> Finding and opening a file is one of the major items
> for compilation times. Also, in Mark's version, the
> compiler must scan all the code looking for the
> #endif, which takes time.

No!

The C preprocessor remembers the names of *idempotent* header files
and will *not* attempt to find, open or read them a second time.
Your suggestion is out-of-date and no longer necessary or useful.

"E. Robert Tisdale" <> writes:
> Thomas Matthews wrote:
>
> > The file opening time may be reduced by using:
> > #ifndef FOO_H_INCLUDED
> > #include "foo.h"
> > #endif
> > Finding and opening a file is one of the major items
> > for compilation times. Also, in Mark's version, the
> > compiler must scan all the code looking for the
> > #endif, which takes time.
>
> No!
>
> The C preprocessor remembers the names of *idempotent* header files
> and will *not* attempt to find, open or read them a second time.
> Your suggestion is out-of-date and no longer necessary or useful.

No, some implementations of the C preprocessor do this. I have no
idea how many, but it's unwise to assume that they all do. (Not that
it matters, since there's no real functional difference.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

E. Robert Tisdale wrote:

> The C preprocessor remembers the names of *idempotent* header files
> and will *not* attempt to find, open or read them a second time.
> Your suggestion is out-of-date and no longer necessary or useful.

Cammon, you know better than that! Of course, _some_ implementations might
do this, but then if you want to bring up implementation-specific features,
then I could chime in and say we're all fool for discussing this topic
given that precompiled headers exist.

--
gabriel