Dividing source code into .h and .c files to be included from the main file

or listening

well typically you put in your .h any public interfaces for your code - struct definitions, global variable type information, function prototypes - anything that does not generate code, or data objects

guard your .h's from multiple inclusions with
#ifndef XXXX_FILE_H
#define XXXX_FILE_H
...stuff
#endif

anything that makes an data object, or generates code goes in your .c

A common way of handling this situation is to have multiple header files. One header file has the common declarations, then the other header files reference the common declarations using extern.

Example:

file_main.h
int variable1;
int variable2;

fileA.h
extern int variable1;
extern int variable2;

fileB.h
extern int variable1;
extern int variable2;
int fileB_variable;

This way you include file_main.h only once in your program, then each of your c files can have its own header file without the duplicate symbol problem.

David

What ever you do, don't do what dceads is suggesting -
it's a maintenance nightmare to have the same variable
'extern'ed in more than one place AND it's very bad
to declare a variable in a .h file.

Here are some suggestions:
For subroutines that are implemented in file_a.c, and
are globally accessible, stick the prototype in
file_a.h.

For #defines (and enums) and structure definitions that
are used predominantly in
file_a.c, and their values are needed by other modules,
e.g. to interpret a return value, or to specify parameter
values, then place the #defines in file_a.h.

For globally visible variables, declare them in file_a.c,
AND put an extern in file_a.h, e.g.
file_a.c
int global_var;
file_a.h
extern int global_var;
and ensure that file_a.c #includes file_a.h.

For any functionality, e.g. #defines, variables,
subroutines that is NOT needed external to the module,
keep that functionality in the .c module that needs is, and don't
advertise it in any .h files.

And as mentioned earlier, it's a good idea to put
#include guards in your .h files, e.g.
file_c.h

#if !defined( _FILE_C_H_ )
#define _FILE_C_H

/* All your .h file stuff */

#endif

This ensures that if the .h file is included by the
same .c module more than once, the guts of the .h file
will only be looked at once while the compiler is
compiling that particular .c module.

And don't worry about the number of times a particular
.h file is included by different .c modules.  I often
have a .h file that includes simple typedefs, e.g.
typedef unsigned char UINT8; and then I #include that
.h file in ALL my .c files.

Hope this helps.

honey_hamster is right.

I was listening because I program in mostly C++ and use classes, so I was wondering what people do in C.  

It is not a good idea to use extern unless you have to, this can cause the same type of side-effects as a global variable in a .c file.

.02

exactly :

only define the variable in one place!!

if you have to use globals

use the same .h for declaring and defining

something like

EXTERN variable_spec;

then include once with EXTERN=extern
and once with EXTERN=

that way you keep always in sync

anovickis is right,
use ifndef... define

or make sure if you include fileA in fileB and then fileB in main, do not include fileA in main, same if you have fileC that includes fileB, and fileB includes fileA, do not include fileA in fileC if you included fileB, and do not include fileA or fileB in main, if fileC is included

Should I put the guards everywhere the files are included?

How does the preprocessor work? Dots are converted to underscore?

so if I want to include fileA.h it should be:
ifndef FILEA_H
#define FILEA_H

or
#ifndef FILEA_H
#define FILEA_H
#include "filea.h"
#endif

It is not case sensitive?

in your include file do this

#ifndef XXXX_FILE_H
#define XXXX_FILE_H

/* put everything in your include file you want here */


#endif





the XXXX_FILE_H is a unique name .. i use the file name of the include file or something like it



this is specifically to keep you out of class of problems where you have a dependancy tree in include files that somehow "mysteriously" includes the same file more than once

wquiot, you ask:

How does the preprocessor work? Dots are converted to underscore?

so if I want to include fileA.h it should be:
ifndef FILEA_H
#define FILEA_H

FILEA_H is simply a label, with no real meaning, other than it is a defined label.  You just as easily can write:

ifndef I_HAVE_INCLUDED_FILEA_H
#define I_HAVE_INCLUDED_FILEA_H
/*  all your stuff here */
#endif

in addition to what has already  been said..
some times u can use extern safely!! .. like if u have multiple source files and u made lots header files .. but there is one function that is defined in b.c and u wanna use it in a.c ,and some how u cudnt manage it in ur header files,  then extern-declare it in a.c..
btw using extern isnt that unsafe .. unless u know very well where r u using which function/variable ..

extern feature is there because many times its useful...had it been UNSAFE .. it would have disappeared

if u think .c files as class source .. then corresponding .h is ALMOST similar to the class prototypes public stuff.. and u dont need to have a .h corresponding to each .c

also make sure in case u want to produce library from your code and u think that function will not be of any use to the user of the library or u dont want him to see that function..