.h files

[johnnash]

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.

 

[Barry Schwarz]

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.

Yes. Doing so will also provide the additional benefit that the
compiler can verify the function prototype and function definition
match.


Remove del for email

 

[Malcolm McLean]

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.

You can, but it is best to put prototypes in a .h file named after the .c
file in which they are defined.

So you have a.c, a.h, b.c, b.h, and maybe AAA.h containing structures common
to both a.c and b.c.

Now define all.h

#include "AAA.h"
#include "a.h"
#include "b.h"

if you just want to include just one header in your main.c file.

 

[CBFalconer]

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.

 

[Kenneth Brody]

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:[email protected]>

 

[CBFalconer]

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.

If you want this I suggest you get it by: Create a.h and b.h. Now
create all.h, which has the lines:

#include "a.h"
#include "b.h"

possibly accompanied by various guards. Now you have full future
flexibility.