473,324 Members | 2,531 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,324 software developers and data experts.

#include optimization

Hi,

I am currently maintaining a legacy code with a very very large code base.
I am facing problems with C/C++ files having a lot of un-necessary #includes.
On an average every C/C++ file has around 150+ .h files included. I find 75%
of the files unnecessary and could be removed. Considering the fact that I
have a huge code base, I can't manually fix it.

Are there any tools that would report un wanted .h files?

I am not sure if this is a right group to ask this question.
I would appreciate if any pointers could be provided.

Thanks
Ramesh
Jul 22 '05 #1
28 3813
In <11*************************@posting.google.com> ra******@gmail.com (Ramesh) writes:
I am currently maintaining a legacy code with a very very large code base.
I am facing problems with C/C++ files having a lot of un-necessary #includes.
On an average every C/C++ file has around 150+ .h files included. I find 75%
of the files unnecessary and could be removed. Considering the fact that I
have a huge code base, I can't manually fix it.


If it ain't broken, don't fix it.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Jul 22 '05 #2
Hi,

Why are the #include's not wanted? I would assume the included files
contain #define's that prevent the code in the files to be loaded more
than once by the preprocessor?

Regards,
Peter Jansson
http://jansson.net/

Jul 22 '05 #3
Ramesh wrote:
Hi,

I am currently maintaining a legacy code with a very very large code base.
I am facing problems with C/C++ files having a lot of un-necessary #includes.
On an average every C/C++ file has around 150+ .h files included. I find 75%
of the files unnecessary and could be removed. Considering the fact that I
have a huge code base, I can't manually fix it.

Are there any tools that would report un wanted .h files?

I am not sure if this is a right group to ask this question.
I would appreciate if any pointers could be provided.

Thanks
Ramesh


You could always write your own.

You may want to consider this technique:
#ifndef HEADER_SYMBOL
#include "header_file.h"
#endif
which could speed up compilation by not having to open
header files, then encounter the guard, then read until
EOR to reach the end of the guard, and close the file.

But this is more of a quality of implementation issue.
Some compilers may be smart enough not to open the
header files already.

--
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.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book

Jul 22 '05 #4
Da*****@cern.ch (Dan Pop) writes:
In <11*************************@posting.google.com>
ra******@gmail.com (Ramesh) writes:
I am currently maintaining a legacy code with a very very large code
base. I am facing problems with C/C++ files having a lot of
un-necessary #includes. On an average every C/C++ file has around
150+ .h files included. I find 75% of the files unnecessary and
could be removed. Considering the fact that I have a huge code base,
I can't manually fix it.


If it ain't broken, don't fix it.


Unless fixing it will make future maintenance easier, which is
probably the case here.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jul 22 '05 #5
On Tue, 28 Sep 2004 18:33:44 GMT, Thomas Matthews
<Th****************************@sbcglobal.net> wrote:
Ramesh wrote:
Hi,

I am currently maintaining a legacy code with a very very large code base.
I am facing problems with C/C++ files having a lot of un-necessary #includes.
On an average every C/C++ file has around 150+ .h files included. I find 75%
of the files unnecessary and could be removed. Considering the fact that I
have a huge code base, I can't manually fix it.

Are there any tools that would report un wanted .h files?

I am not sure if this is a right group to ask this question.
I would appreciate if any pointers could be provided.

Thanks
Ramesh


You could always write your own.

You may want to consider this technique:
#ifndef HEADER_SYMBOL
#include "header_file.h"
#endif
which could speed up compilation by not having to open
header files, then encounter the guard, then read until
EOR to reach the end of the guard, and close the file.

But this is more of a quality of implementation issue.
Some compilers may be smart enough not to open the
header files already.


That doesn't really answer the OP's question, though. I don't know of
any such tool, though it would be useful at times. I've done the
equivalent manually, by ifdef'ing out header files and checking
whether they still compile.

--
Al Balmer
Balmer Consulting
re************************@att.net
Jul 22 '05 #6
Ramesh wrote:
I am currently maintaining a legacy code with a very very large code base.
I am facing problems with C/C++ files having a lot of un-necessary #includes.
You are probably mistaken.
Good programmers don't include header files that aren't necessary.
On an average every C/C++ file has around 150+ .h files included.
I find 75% of the files unnecessary and could be removed.
How did you determine that?
Considering the fact that I have a huge code base,
I can't manually fix it.
What, exactly, are you trying to fix?
Are there any tools that would report un wanted .h files?
Of course not. How would such a tool know
what should and shouldn't be in any given header file?
Try this:
cat file.h #ifndef GUARD_FILE_H
#define GUARD_FILE_H 1
#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>
#include <math.h>
#include <string.h>
#include <values.h>
#include <time.h>
#include <signal.h>
#endif//GUARD_FILE_H
cat file1.c #include "file.h"
time gcc -Wall -std=c99 -pedantic -c file1.c 0.133u 0.049s 0:00.18 94.4% 0+0k 0+0io 0pf+0w cat file128.c

#include "file.h"
#include "file.h"
Jul 22 '05 #7
Hi,

I have used a program called 'lint' before to QA C/C++ code. One of the
errors the SUN version reported was unused header files. This may prove
useful to you.

Regards

Clive
"Ramesh" <ra******@gmail.com> wrote in message
news:11*************************@posting.google.co m...
Hi,

I am currently maintaining a legacy code with a very very large code base.
I am facing problems with C/C++ files having a lot of un-necessary
#includes.
On an average every C/C++ file has around 150+ .h files included. I find
75%
of the files unnecessary and could be removed. Considering the fact that I
have a huge code base, I can't manually fix it.

Are there any tools that would report un wanted .h files?

I am not sure if this is a right group to ask this question.
I would appreciate if any pointers could be provided.

Thanks
Ramesh

Jul 22 '05 #8
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in
news:cj**********@nntp1.jpl.nasa.gov:
Ramesh wrote:
I am currently maintaining a legacy code with a very very large code
base. I am facing problems with C/C++ files having a lot of
un-necessary #includes.
You are probably mistaken.
Good programmers don't include header files that aren't necessary.


You're assuming that the previous programmers in that project were good.
On an average every C/C++ file has around 150+ .h files included.
I find 75% of the files unnecessary and could be removed.


How did you determine that?


Probably by cursory examination. Keep in mind that the OP isn't talking
about every C/C++ file as in every one in existance, only the ones in his
project. Neither is the OP intending to be exact with the statistics.
The OP is merely indicating that he has noticed an appreciable number of
header files that do not appear to be contributing anything useful to
certain translation units.
Considering the fact that I have a huge code base,
I can't manually fix it.


What, exactly, are you trying to fix?


Excessive includes causing the compiler to load too many files.
Are there any tools that would report un wanted .h files?


Of course not. How would such a tool know
what should and shouldn't be in any given header file?


By examining what symbols are used in each giving translation unit, and
removing those header files that don't mention any of those symbols.
(OK, that's probably grossly simplified, and in no way am I trying to
imply that this would be an _easy_ task...)
Try this:
[snip some example about including the same file many times in one
translation unit]
which shows that it doesn't take any more time to process
a header file 128 time than it takes to process it once!
Once the C preprocessor has read an idempotent file,
it doesn't read it again no matter how many times it is included.


However, the OP's problem is that there exists many source files which
include "extra" header files. Not that one single file is including the
same header file over and over again.
Jul 22 '05 #9
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
Ramesh wrote:
I am currently maintaining a legacy code with a very very large
code base. I am facing problems with C/C++ files having a lot of
un-necessary #includes.
You are probably mistaken.
Good programmers don't include header files that aren't necessary.


But I wouldn't be at all surprised to find that the previous
programmers on his project cut-and-pasted some large set of #include
directives into each *.c file by rote, or that the set of #include
directives just grew over the years. Not all programmers are good
programmers (and even good programmers aren't good all the time).
Maintenance programmers often have to deal with the consequences of
other people's sloppiness.
On an average every C/C++ file has around 150+ .h files included.
I find 75% of the files unnecessary and could be removed.
If a single C (or C++) source file has over 150 #include directives,
there's probably a serious problem. If an *average* source file has
that many #include directives, this approaches certainty.

For that matter, if only 75% of them are superfluous, that still
leaves an average of nearly 40 #includes per source file, which is
more than I'd be comfortable with.

If the system is that poorly structured, it might be best to leave it
alone and make only careful incremental changes, but if you want to
try to get a handle on it, deleting the superfluous #includes could be
a good start.

[...]
Try this:


[snip] > time gcc -Wall -std=c99 -pedantic -c file128.c

0.144u 0.039s 0:00.19 89.4% 0+0k 0+0io 0pf+0w

which shows that it doesn't take any more time to process
a header file 128 time than it takes to process it once!
Once the C preprocessor has read an idempotent file,
it doesn't read it again no matter how many times it is included.


That may be true for gcc, but the OP didn't say he's using gcc. In
any case, the OP didn't say that compilation time is what he's worried
about. Programmer time is far more valuable than compilation time;
simplifying the code could save significantly on programmer time.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jul 22 '05 #10
On 28 Sep 2004 05:35:28 -0700, ra******@gmail.com (Ramesh) wrote in
comp.lang.c:
Hi,

I am currently maintaining a legacy code with a very very large code base.
I am facing problems with C/C++ files having a lot of un-necessary #includes.
On an average every C/C++ file has around 150+ .h files included. I find 75%
of the files unnecessary and could be removed. Considering the fact that I
have a huge code base, I can't manually fix it.

Are there any tools that would report un wanted .h files?

I am not sure if this is a right group to ask this question.
I would appreciate if any pointers could be provided.

Thanks
Ramesh


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

I have verified this capability with C files, and have no reason to
doubt that it can do this with C++ source as well.

If the project is not being build on a PC, they make a much more
expensive for *nix types of systems. It may be feasible to import the
source tree onto a Windows PC just to run the PC version of the
product, which is a bargain at its price.

--
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
Jul 22 '05 #11
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:
Good programmers don't include header files that aren't necessary.


How many good programmers do you know who include 150+ header files in
their source files?
Jul 22 '05 #12
Suzie wrote:
E. Robert Tisdale wrote:
Good programmers don't include header files that aren't necessary.


How many good programmers do you know
who include 150+ header files in their source files?


I think Ramesh was trolling.
Jul 22 '05 #13
Alan Balmer <al******@att.net> wrote in
news:t9********************************@4ax.com:
That doesn't really answer the OP's question, though. I don't know of
any such tool, though it would be useful at times. I've done the
equivalent manually, by ifdef'ing out header files and checking
whether they still compile.


That can work as long as you look out for headers containing

#define ENABLE_XYZ_FEATURE

and a CPP file containing

#ifdef ENABLE_XYZ_FEATURE
:
#endif

In this case, removing the header might not prevent the software from
compiling, but it might change what is being generated.

Gregg
Jul 22 '05 #14
Thank a lot guys. Actually I was thinking about the questions raised in
my mind...
A lot of things could have been done better...... But the reality is
that,
with no offence to the developers, the current state of the code is
pretty bad
and it needs to be fixed.

The problem with these lot of un wanted #includes is that my
development
platform is Tandem and as I understand, the file open and close are the
most
expensive operations on the platform. Unfortunately we dont use a
cross compiler
and depend on a native compiler that needs to be run on the Tandem!!

In general the compilation is pretty slow and with these header
problems it takes
forever to compile!!

There are 2 problems that needs to be addressed.

(1)Multiple inclusions

eg:

b.h
----
#include<a.h>
....
....

c.h
----
#include<a.h>
#include<b.h>

Now the include of a.h in c.h is not needed.

Although a.h has macro guards and it would not be included twice,
the compiler still needs to open and close a.h file twice.

As suggested,I can move the guards to the top and so my c.h file
can be changed to

#ifndef A_H
#include <a.h>
#endif
....

So this is kinda feasible for scripting.. just read all the .h files
and
get the macro guard string and change all occurances of #include with
the
enclosing guard.
(2) The second problem is un-necessary #includes. Over a period of time
the
developers have got a set of #includes that they add to the files
without
thinking!!

for eg: consider

#include<stdio.h>
#include<sys/types.h>
#include<sys/socket.h>
int main(int argc,char** argv){
printf("Hello World\n");
}

Here the includes for types and socket is unnecessary.

This involves 2 file opens on this level that could be avoided.

I want to fix this also.

But I am unable to come out with some solution...

Anyone has some ideas on how to do this...

There were 2 options suggested. lint on sun and PCLint
I will give it a shot this week.

Thanks once again for the help

Ramesh

Jul 22 '05 #15
Ramesh Natarajan wrote:

(2) The second problem is un-necessary #includes. Over a period of time
the
developers have got a set of #includes that they add to the files
without
thinking!!

for eg: consider

#include<stdio.h>
#include<sys/types.h>
#include<sys/socket.h>
int main(int argc,char** argv){
printf("Hello World\n");
}

Here the includes for types and socket is unnecessary.

This involves 2 file opens on this level that could be avoided.

I want to fix this also.

But I am unable to come out with some solution...


Hmm. Just a quick shot. The idea is:

Write a program which reads and modifies a source file. The program
drops one of the includes and afterwards starts the compiler on the
modified source. If the compiler doesn't complain, the include was
unnecesary and is permanenlty dropped. If the compiler emits an error
then the drop is undone.
Your program checks every include in this way and thus keeps only the
needed ones.

--
Karl Heinz Buchegger
kb******@gascad.at
Jul 22 '05 #16
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <11*************************@posting.google.com>
ra******@gmail.com (Ramesh) writes:
I am currently maintaining a legacy code with a very very large code
base. I am facing problems with C/C++ files having a lot of
un-necessary #includes. On an average every C/C++ file has around
150+ .h files included. I find 75% of the files unnecessary and
could be removed. Considering the fact that I have a huge code base,
I can't manually fix it.


If it ain't broken, don't fix it.


Unless fixing it will make future maintenance easier, which is
probably the case here.


Why?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Jul 22 '05 #17
Hi there,
I am currently maintaining a legacy code with a very very large code
base. I am facing problems with C/C++ files having a lot of
un-necessary #includes. On an average every C/C++ file has around
150+ .h files included. I find 75% of the files unnecessary and
could be removed. Considering the fact that I have a huge code base,
I can't manually fix it.

If it ain't broken, don't fix it.


Unless fixing it will make future maintenance easier, which is
probably the case here.


Why?


I cannot look into Keith's head but one possible reason is that
from looking at which file includes which header you get information
where to look when changing something.

Especially in huge codes with many man years of work in them and
too few man days of documentation work and me not being an expert,
this (e.g. by find . -type f -exec grep obscureheader.h \{} -print)
is -- after browsing around with tags -- one step I might
take to get a feeling for how this connects with that and whether some
people took "shortcuts" somewhere that need to be fixed.
If you basically have people including about fifty header files for
no reason in every translation unit they get into their hands so
that they do not have to know about where which functions, definitions
and so on come from, then this approach obviously is not feasible.

Just a guess.
Cheers
Michael

Jul 22 '05 #18
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message news:<cj**********@nntp1.jpl.nasa.gov>...
Ramesh wrote:
I am currently maintaining a legacy code with a very very large code base.
I am facing problems with C/C++ files having a lot of un-necessary
#includes.
You are probably mistaken.
Good programmers don't include header files that aren't necessary.


Yes they do, on occasion. It's possible that the original programmers
weren't very good. It's also possible that the headers were necessary
at one time, but over time the code was hacked beyond recognition and
the symbols in those headers are no longer being used in that source
file. Or it could be the result of a cut-and-paste fest stemming from
unclear requirements and a laughably unrealistic schedule.

I've seen this movie more than once. Hell, I'm *in* the movie.
On an average every C/C++ file has around 150+ .h files included.
I find 75% of the files unnecessary and could be removed.


How did you determine that?


By checking to see if the source file actually *uses* any of the
symbols defined in the header file maybe?
Considering the fact that I have a huge code base,
I can't manually fix it.


What, exactly, are you trying to fix?


He is trying to remove unnecessary #include directives, thereby making
the code easier to read and maintain (and maybe save some cycles
during builds).
Are there any tools that would report un wanted .h files?


Of course not. How would such a tool know
what should and shouldn't be in any given header file?


The tool could scan each header file for symbols (macros, typedefs,
enums, function declarations, external variable declarations) and then
check the source file to see if any of those symbols are present. If
none of the symbols in the header are present in the source file, then
the tool can mark that header as (probably) superfluous. I don't
personally know of any tool that does that particular job, and I won't
claim that it would be easy to write one (handling nested includes
would be "fun"), but it can be done (lex/flex and yacc/bison would
probably be the best way to go about it).

Try this:
> cat file.h

#ifndef GUARD_FILE_H
#define GUARD_FILE_H 1
#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>
#include <math.h>
#include <string.h>
#include <values.h>
#include <time.h>
#include <signal.h>
#endif//GUARD_FILE_H
> cat file1.c

#include "file.h"
> time gcc -Wall -std=c99 -pedantic -c file1.c

0.133u 0.049s 0:00.18 94.4% 0+0k 0+0io 0pf+0w
> cat file128.c

#include "file.h"
#include "file.h"
.
.
.
#include "file.h"
> time gcc -Wall -std=c99 -pedantic -c file128.c

0.144u 0.039s 0:00.19 89.4% 0+0k 0+0io 0pf+0w

which shows that it doesn't take any more time to process
a header file 128 time than it takes to process it once!
Once the C preprocessor has read an idempotent file,
it doesn't read it again no matter how many times it is included.


But that's not really the OP's problem, is it?
Jul 22 '05 #19
Karl Heinz Buchegger wrote:
Ramesh Natarajan wrote:
(2) The second problem is un-necessary #includes. Over a period of time
the
developers have got a set of #includes that they add to the files
without
thinking!!

for eg: consider

#include<stdio.h>
#include<sys/types.h>
#include<sys/socket.h>
int main(int argc,char** argv){
printf("Hello World\n");
}

Here the includes for types and socket is unnecessary.

This involves 2 file opens on this level that could be avoided.

I want to fix this also.

But I am unable to come out with some solution...

Hmm. Just a quick shot. The idea is:

Write a program which reads and modifies a source file. The program
drops one of the includes and afterwards starts the compiler on the
modified source. If the compiler doesn't complain, the include was
unnecesary and is permanenlty dropped. If the compiler emits an error
then the drop is undone.
Your program checks every include in this way and thus keeps only the
needed ones.


Such a program would also need to verify that the resulting executable
is identical.

Alan
Jul 22 '05 #20
Da*****@cern.ch (Dan Pop) writes:
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <11*************************@posting.google.com>
ra******@gmail.com (Ramesh) writes:
I am currently maintaining a legacy code with a very very large code
base. I am facing problems with C/C++ files having a lot of
un-necessary #includes. On an average every C/C++ file has around
150+ .h files included. I find 75% of the files unnecessary and
could be removed. Considering the fact that I have a huge code base,
I can't manually fix it.

If it ain't broken, don't fix it.


Unless fixing it will make future maintenance easier, which is
probably the case here.


Why?


Because.

Take a look at what's been said so far. The source files have an
average of about 150 #include directives, most of which are
unnecessary. It's a "very very large code base". It seems fairly
obvious to me that the whole thing is a mess, and that cleaning it up
would make it easier to maintain. (I'm tempted to suggest the
possibility of throwing it away and starting from scratch, but that's
probably not feasible.)

Maybe it isn't really a problem, or maybe the unnecessary #includes
are such a small part of the problem that eliminating them wouldn't
really help, which is why I qualified my statement with the word
"probably". But since Ramesh specifically said that it's a problem,
and he's asking for ways to fix it, I'm not going to assume that he's
mistaken about the premise for his question.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jul 22 '05 #21
Keith Thompson wrote:
Da*****@cern.ch (Dan Pop) writes:
Keith Thompson <ks***@mib.org> writes:
Da*****@cern.ch (Dan Pop) writes:
ra******@gmail.com (Ramesh) writes: I am currently maintaining a legacy code with a very very large
> code base. I am facing problems with C/C++ files having a lot
> of un-necessary #includes. On an average every C/C++ file has
> around 150+ .h files included. I find 75% of the files
> unnecessary and could be removed. Considering the fact that I
> have a huge code base, I can't manually fix it.

If it ain't broken, don't fix it.

Unless fixing it will make future maintenance easier, which is
probably the case here.


Why?


Because.

Take a look at what's been said so far. The source files have an
average of about 150 #include directives, most of which are
unnecessary. It's a "very very large code base". It seems fairly
obvious to me that the whole thing is a mess, and that cleaning it
up would make it easier to maintain. (I'm tempted to suggest the
possibility of throwing it away and starting from scratch, but
that's probably not feasible.)

Maybe it isn't really a problem, or maybe the unnecessary #includes
are such a small part of the problem that eliminating them wouldn't
really help, which is why I qualified my statement with the word
"probably". But since Ramesh specifically said that it's a
problem, and he's asking for ways to fix it, I'm not going to
assume that he's mistaken about the premise for his question.


Actually it is a job that can be attacked and checked piecemeal.
Remove the (presumably) useless includes in one file by commenting
out (thus retaining line numbers) and compile it to an object
file. Do a binary compare against the original object file. If
identical, all is well. If not, investigate the causes (which may
include a compilation datestamp). This assumes that the system
will not generate external linkages on seeing only a prototype.

Another approach revolves around a cross referance, or the
interactive equivalent supplied by cscope.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 22 '05 #22
CBFalconer wrote:
Keith Thompson wrote:
Da*****@cern.ch (Dan Pop) writes:
Keith Thompson <ks***@mib.org> writes:

Da*****@cern.ch (Dan Pop) writes:

>ra******@gmail.com (Ramesh) writes:

>>I am currently maintaining a legacy code with a very very large
>>code base. I am facing problems with C/C++ files having a lot
>>of un-necessary #includes. On an average every C/C++ file has
>>around 150+ .h files included. I find 75% of the files
>>unnecessary and could be removed. Considering the fact that I
>>have a huge code base, I can't manually fix it.
>
>If it ain't broken, don't fix it.

Unless fixing it will make future maintenance easier, which is
probably the case here.

Why?


Because.

Take a look at what's been said so far. The source files have an
average of about 150 #include directives, most of which are
unnecessary. It's a "very very large code base". It seems fairly
obvious to me that the whole thing is a mess, and that cleaning it
up would make it easier to maintain. (I'm tempted to suggest the
possibility of throwing it away and starting from scratch, but
that's probably not feasible.)

Maybe it isn't really a problem, or maybe the unnecessary #includes
are such a small part of the problem that eliminating them wouldn't
really help, which is why I qualified my statement with the word
"probably". But since Ramesh specifically said that it's a
problem, and he's asking for ways to fix it, I'm not going to
assume that he's mistaken about the premise for his question.

Actually it is a job that can be attacked and checked piecemeal.
Remove the (presumably) useless includes in one file by commenting
out (thus retaining line numbers) and compile it to an object
file. Do a binary compare against the original object file. If
identical, all is well.


Even if binary compare shows that there are differences all may be well
too. I learned this the hard way; compiling the same code twice with a
certain compiler yielded different binaries. Apparently the compiler
wrote the build date or something like that into the binary. When debug
information is stored in object files this test may also fail for the
wrong reasons.

--
Peter van Merkerk
peter.van.merkerk(at)dse.nl
Jul 22 '05 #23
Alan Johnson wrote:
Hmm. Just a quick shot. The idea is:

Write a program which reads and modifies a source file. The program
drops one of the includes and afterwards starts the compiler on the
modified source. If the compiler doesn't complain, the include was
unnecesary and is permanenlty dropped. If the compiler emits an error
then the drop is undone.
Your program checks every include in this way and thus keeps only the
needed ones.


Such a program would also need to verify that the resulting executable
is identical.


Ah. right.
#undef xxx
#define xxx something_else
would else be unnoticed

--
Karl Heinz Buchegger
kb******@gascad.at
Jul 22 '05 #24
Peter van Merkerk wrote:
CBFalconer wrote:

... snip ...

Actually it is a job that can be attacked and checked piecemeal.
Remove the (presumably) useless includes in one file by commenting
out (thus retaining line numbers) and compile it to an object
file. Do a binary compare against the original object file. If
identical, all is well.


Even if binary compare shows that there are differences all may be well
too. I learned this the hard way; compiling the same code twice with a
certain compiler yielded different binaries. Apparently the compiler
wrote the build date or something like that into the binary. When debug
information is stored in object files this test may also fail for the
wrong reasons.


Why did you snip the last sentence or two from my paragraph, which
mentioned precisely this problem?

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Jul 22 '05 #25
>>>Actually it is a job that can be attacked and checked piecemeal.
Remove the (presumably) useless includes in one file by commenting
out (thus retaining line numbers) and compile it to an object
file. Do a binary compare against the original object file. If
identical, all is well.


Even if binary compare shows that there are differences all may be well
too. I learned this the hard way; compiling the same code twice with a
certain compiler yielded different binaries. Apparently the compiler
wrote the build date or something like that into the binary. When debug
information is stored in object files this test may also fail for the
wrong reasons.


Why did you snip the last sentence or two from my paragraph, which
mentioned precisely this problem?


Probably because you gave a solution to the problem without stating
the problem...
To be honest, I did not really get what you were aiming at, either.

For completeness, here is the left-out part:
Another approach revolves around a cross referance, or the
interactive equivalent supplied by cscope.


Cheers,
Michael

Jul 22 '05 #26
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <11*************************@posting.google.com>
ra******@gmail.com (Ramesh) writes:
>I am currently maintaining a legacy code with a very very large code
>base. I am facing problems with C/C++ files having a lot of
>un-necessary #includes. On an average every C/C++ file has around
>150+ .h files included. I find 75% of the files unnecessary and
>could be removed. Considering the fact that I have a huge code base,
>I can't manually fix it.

If it ain't broken, don't fix it.

Unless fixing it will make future maintenance easier, which is
probably the case here.
Why?


Because.

Take a look at what's been said so far. The source files have an
average of about 150 #include directives, most of which are
unnecessary. It's a "very very large code base". It seems fairly
obvious to me that the whole thing is a mess, and that cleaning it up
would make it easier to maintain. (I'm tempted to suggest the
possibility of throwing it away and starting from scratch, but that's
probably not feasible.)


One could merge all the 150 headers in a single header and you'll see
a single header being included instead of 150. Including that header
will also provide some unnecessary definitions and declarations, but this
is no different from including <stdlib.h> and getting more declarations
than your application actually needs (when was the last time you included
<stdlib.h> and used everything declared within?).

So, the fact that the source files include 150 headers, not all of them
necessary to each source file, is not a problem in itself. If the
maintainer is annoyed by seeing such a bunch of includes everywhere,
he can trivially write a new header, that includes all the application
headers, and include only this header in each source file.
Maybe it isn't really a problem, or maybe the unnecessary #includes
are such a small part of the problem that eliminating them wouldn't
really help, which is why I qualified my statement with the word
"probably". But since Ramesh specifically said that it's a problem,
and he's asking for ways to fix it, I'm not going to assume that he's
mistaken about the premise for his question.


And I'm not going to believe him until provided with *concrete* examples.

I'm tempted to believe that the mistake was creating so many application
specific headers in the first place and the *right* fix would be to
drastically reduce their number. Without knowing the specifics, there
is no way of telling whether merging all of them in a single header
(e.g. by using another header that includes all of them) is the right
fix or if there is a real need for more than one application specific
header. But I'm reasonably convinced that there is no need for 150 header
files.

OTOH, I'm reasonably convinced that their existence is not causing
any maintenance problems, either. It's just that the source files
containing so many include directives look mildly annoying.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Jul 22 '05 #27
Michael Mair wrote: *** And removed attributions ***
Actually it is a job that can be attacked and checked piecemeal.
Remove the (presumably) useless includes in one file by commenting
out (thus retaining line numbers) and compile it to an object
file. Do a binary compare against the original object file. If
identical, all is well.

Even if binary compare shows that there are differences all may be
well too. I learned this the hard way; compiling the same code
twice with a certain compiler yielded different binaries.
Apparently the compiler wrote the build date or something like
that into the binary. When debug information is stored in object
files this test may also fail for the wrong reasons.


Why did you snip the last sentence or two from my paragraph, which
mentioned precisely this problem?


Probably because you gave a solution to the problem without stating
the problem...
To be honest, I did not really get what you were aiming at, either.

For completeness, here is the left-out part:
Another approach revolves around a cross referance, or the
interactive equivalent supplied by cscope.
Wrong left-out part, which was as follows, and was an integral
portion of the quoted paragraph:
identical, all is well. If not, investigate the causes (which may
include a compilation datestamp). This assumes that the system
will not generate external linkages on seeing only a prototype.


Your elimination of attributions leaves the (mistaken) impression
that I was complaining about your actions, while the actual
offender was Peter van Merkerk.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 22 '05 #28
[Me messing up a discussion I did not take part in]

For completeness, here is the left-out part:

Another approach revolves around a cross referance, or the
interactive equivalent supplied by cscope.

Wrong left-out part, which was as follows, and was an integral
portion of the quoted paragraph:
Argh, sorry, I did so not get it :-(
identical, all is well. If not, investigate the causes (which may
include a compilation datestamp). This assumes that the system
will not generate external linkages on seeing only a prototype.


Your elimination of attributions leaves the (mistaken) impression
that I was complaining about your actions, while the actual
offender was Peter van Merkerk.


Er, right. Was a quick one when compiling my crap...
More thinking before sending next time.
Once again, sorry for messing it up!

--Michael

Jul 22 '05 #29

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

18
by: Exits Funnel | last post by:
Hello, I'm a little confused about where I should include header files and was wondering whether there was some convention. Imagine I've written a class foo and put the definition in foo.h and...
9
by: Rune | last post by:
Is it best to use double quotes and let PHP expand variables inside strings, or is it faster to do the string manipulation yourself manually? Which is quicker? 1) $insert = 'To Be';...
12
by: WantedToBeDBA | last post by:
Hi all, db2 => create table emp(empno int not null primary key, \ db2 (cont.) => sex char(1) not null constraint s_check check \ db2 (cont.) => (sex in ('m','f')) \ db2 (cont.) => not enforced...
27
by: Ramesh | last post by:
Hi, I am currently maintaining a legacy code with a very very large code base. I am facing problems with C/C++ files having a lot of un-necessary #includes. On an average every C/C++ file has...
0
by: Francois | last post by:
Hi, I think I found a bug with VS, and I've included a project example of the problem I got. I've got a project deep into a set of folders. The project have an additional include library...
3
by: Arpi Jakab | last post by:
I have a main project that depends on projects A and B. The main project's additional include directories list is: ...\ProjectA\Dist\Include ...\ProjectB\Dist\Include Each of the include...
5
by: wkaras | last post by:
I've compiled this code: const int x0 = 10; const int x1 = 20; const int x2 = 30; int x = { x2, x0, x1 }; struct Y {
18
by: gutmant | last post by:
Say you have a file, a.h with an include guard. If you include it twice and look at the preprocessed output, you see there's no sign for the second inclusion. However, if you include it twice -...
20
by: Ravikiran | last post by:
Hi Friends, I wanted know about whatt is ment by zero optimization and sign optimization and its differences.... Thank you...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.