CBFalconer wrote:
>
johnnash wrote:
Ok I have a doubt regarding .h files. I basically have two modules
in my software program - a.c and b.c
There is .h file called d.h. d.h contains prototypes of functions
in a.c so whenever i have to use functions of a.c i simply need to
include d.h. My question is can i also add the prototypes of
functions in b.c in d.h so that i only need to d.h in main.c so as
to access functions of both a.c and b.c.
No. You should match header files with source files, so each
expresses the external access permitted to the content of that
source file. You should have a.h an b.h, and #include the h files
for the units you use.
I disagree here, to a point. If a.c and b.c are related, perhaps as
part of a library, then a single .h file should be used. Consider,
for example, the stdlib.h header file, which contains prototypes of
many functions. I would like to think (and I happen to know for a
fact, on the systems I've checked) that these functions are actually
defined in separate source modules.
Now, if the only relationship a.c and b.c have is that they happen
to both be part of this program that's being written, then it makes
sense to have separate a.h and b.h files, and perhaps a wrapper file
for the project that #include's both.
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody |
www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net |
www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
