finding redundant #includes to shorten compile time

[Benjamin Rutt]

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

[Mark A. Odell]

Benjamin Rutt <br********@bloomington.in.us> wrote in
news:wc*************@mu.cis.ohio-state.edu:

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

[Benjamin Rutt]

"Mark A. Odell" <no****@embeddedfw.com> 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

[gabriel]

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

[Thomas Matthews]

Mark A. Odell wrote:

Benjamin Rutt <br********@bloomington.in.us> wrote in
news:wc*************@mu.cis.ohio-state.edu:

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

[Mark A. Odell]

Thomas Matthews <Th****************************@sbcglobal.net> wrote in
news:tK*******************@newssvr16.news.prodigy. 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 ->
--

[Jack Klein]

On Thu, 05 Feb 2004 11:49:31 -0500, Benjamin Rutt
<br********@bloomington.in.us> 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

[E. Robert Tisdale]

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.

[Keith Thompson]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> 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) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[gabriel]

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

[E. Robert Tisdale]

Keith Thompson wrote:

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

It is *unwise* to cobble your code
just to accommodate an inferior C preprocessor.
If your C preprocessor does not implement this optimization,
it's time to shop around for a better C compiler.

[Default User]

gabriel wrote:

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.

You have to understand that Trollsdale believes his implementation is
the only one in the world. So anything true for it is true for all.

Brian Rodenborn

[Richard Heathfield]

E. Robert Tisdale wrote:

<snip>

It is *unwise* to cobble your code
just to accommodate an inferior C preprocessor.
If your C preprocessor does not implement this optimization,
it's time to shop around for a better C compiler.

Some platforms have a limited number of C implementations (e.g. just one or
two). If none of the implementations available for a particular platform
implement the feature you desire, what would you recommend? Changing the
platform?

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[gabriel]

Richard Heathfield wrote:

platform implement the feature you desire, what would you recommend?
Changing the platform?

Write your own compiler, like real men do!

Just kidding...

--
gabriel

[Dan Pop]

In <wc*************@mu.cis.ohio-state.edu> Benjamin Rutt <br********@bloomington.in.us> writes:

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,

The easiest approach is not to include unnecessary headers in the first
place.

Anyway, unless they reside on a particularly slow medium, headers increase
the compilation time by an insignificant amount.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[CBFalconer]

Richard Heathfield wrote:

E. Robert Tisdale wrote:

<snip>

It is *unwise* to cobble your code
just to accommodate an inferior C preprocessor.
If your C preprocessor does not implement this optimization,
it's time to shop around for a better C compiler.

Some platforms have a limited number of C implementations (e.g.
just one or two). If none of the implementations available for a
particular platform implement the feature you desire, what would
you recommend? Changing the platform?

Hell no. Simply advise Trollsdale and he will have a compiler
ready for you in the next 48 hours. It will have excellent
specifications. A minor problem might be that it won't meet them,
and that it reports success or failure by crashing. A
compensation may be that it is subject to buffer overruns, so with
a bit of practice you can write a source that patches it on the
fly.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!