header file size effect

[bobby]

hi group,

Does the header file size or number in include(s) effect the size of
executable file?
In other world if i chose a large header file and include it with my
source file does it increase the size of the executable outcome at the
end?

thanks

 

[Malcolm McLean]

hi group,

Does the header file size or number in include(s) effect the size of
executable file?
In other world if i chose a large header file and include it with my
source file does it increase the size of the executable outcome at the
end?

Typically no.
Header usually contain prototypes and definitions of constants and
structures. All this textual apparatus is stripped away in the process of
compilation. Only code you actually call will inflate the executable.

 

[bobby]

hi group,


Typically no.
Header usually contain prototypes and definitions of constants and
structures. All this textual apparatus is stripped away in the process of
compilation. Only code you actually call will inflate the executable.

This make sense
However I searched and found this forum at : http://forums.pcquest.com/forum/viewtopic.php?t=3999
that indicate "the larger the size of the header file , larger the
size of ur executable"
moreover it adds "Since this is a case of static binding, more the
size of ur executable, more is the system memory utilization"

It also recommend to divide header file into parts/groups so that your
program runs faster and their is no unnecessary searching which might
result in collision of declarations. comes from http://www.codeguru.com/cpp/tic/tic0056.shtml

I appreciate if you can clarify this for me

thanks

 

[osmium]

:

(e-mail address removed)...

This make sense
However I searched and found this forum at :
http://forums.pcquest.com/forum/viewtopic.php?t=3999
that indicate "the larger the size of the header file , larger the
size of ur executable"
moreover it adds "Since this is a case of static binding, more the
size of ur executable, more is the system memory utilization"

It also recommend to divide header file into parts/groups so that your
program runs faster and their is no unnecessary searching which might
result in collision of declarations. comes from
http://www.codeguru.com/cpp/tic/tic0056.shtml

I appreciate if you can clarify this for me

Taking what you said at face value, I would say there is a lot of
mis-information on the Web. Printed too. I saw an article that said C dd
not have a "go to". In the second graf, they said "program" when they meant
"compiler"

 

[Bartc]

This make sense
However I searched and found this forum at :
http://forums.pcquest.com/forum/viewtopic.php?t=3999
that indicate "the larger the size of the header file , larger the
size of ur executable"
moreover it adds "Since this is a case of static binding, more the
size of ur executable, more is the system memory utilization"

That thread was possibly about why standard C headers such as stdio.h,
time.h, always seem to be included individually, and what the penalty would
be of simply including all of them.

In fact why not just include all of them (by using a new header that just
contains a dozen or two #includes), in every program instead of having to
pick and choose every time? All the standard headers combined is still tiny
compared with say windows.h, it shouldn't affect compilation times:

#include <stdc.h>

Seems simple to me.

 

[Malcolm McLean]

This make sense
However I searched and found this forum at :
http://forums.pcquest.com/forum/viewtopic.php?t=3999
that indicate "the larger the size of the header file , larger the
size of ur executable"
moreover it adds "Since this is a case of static binding, more the
size of ur executable, more is the system memory utilization"

It also recommend to divide header file into parts/groups so that your
program runs faster and their is no unnecessary searching which might
result in collision of declarations. comes from
http://www.codeguru.com/cpp/tic/tic0056.shtml

I appreciate if you can clarify this for me

That could be about C++.
In C++ the convention is to place inline code into header files. Inlined
functions do blow u[ the size of the executable. Though it isn't likely to
be an issue on modern PCs, some early programmers got a shock when they saw
just how big their C++ programs were in relation to the same program in C.

 

[Kenneth Brody]

Typically no.
Header usually contain prototypes and definitions of constants and
structures. All this textual apparatus is stripped away in the process of
compilation. Only code you actually call will inflate the executable.

However, "the executable" may contain more information that the
actual executable code and assocaited data. It may, for example,
include debug information, including all symbols which may have
been defined (even if never used) in header files.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[J. J. Farrell]

This make sense
However I searched and found this forum at : http://forums.pcquest.com/forum/viewtopic.php?t=3999
that indicate "the larger the size of the header file , larger the
size of ur executable"
moreover it adds "Since this is a case of static binding, more the
size of ur executable, more is the system memory utilization"

It also recommend to divide header file into parts/groups so that your
program runs faster and their is no unnecessary searching which might
result in collision of declarations. comes from http://www.codeguru.com/cpp/tic/tic0056.shtml

I appreciate if you can clarify this for me

Sure. The first thing you quote is utter and absolute garbage. The
second one is largely about C++ rather than C; I've not read it
thoroughly, but you need to think carefully about the summary you gave.
How many header files will need to be searched if all the relevant
information is in one header? How many will need to be searched if it is
split over several headers? How likely are you to accidentally duplicate
names and declarations if you are maintaining several headers rather
than one?

It's important to think carefully how to arrange your information in
headers. Neither "one" nor "many" is the right answer for all cases. for
small programs with a few .c files, a single header often makes sense.
For larger projects, especially ones which are logically split into
different groups of functionality, it might make sense to have a header
for each of these groups containing the information which is essentially
private to that group, and another to contain all the program-wide
information which pulls the whole thing together.

In general, things like how long it takes to search headers are the last
things you should be worrying about. Forget about it, arrange your
headers logically for the overall program structure. Search times are
only likely to possibly become an issue with really huge projects, and
by the time you're in a position to be making decisions about things
like that you should have enough experience to get it right. One thing
to remember is that these are all compile-time issues only, they have no
effect on the final program. You're worrying about saving milliseconds
of compilation time for small projects, not normally something worth the
effort.