Header files are a module's interface. They let the user of the module know what facilities the module provides and the tools available to manipulate them. The header should include stuff like prototypes for the module's external functions, object definitions and possibly macros.
When I create modules, I try to make that module responsible for manipulating a single type, which is typically encapsulated in a struct.
Consider a simple "stack" module. This module manages a generic stack that is capable of storing any data type. The header might look like this:
stack.h
-------
#ifndef STACK_H
#define STACK_H
/* Stack object */
struct stack {
unsigned long count;
struct stack *tos;
};
/* Create a stack */
extern struct stack *
stack_alloc(void);
/* Destroy a stack */
extern void
stack_free(struct stack *);
/* Push an item on the stack */
extern int
stack_push(struct stack *,const void *,size_t);
/* Pop an item from the stack */
extern void *
stack_pop(struct stack *);
/* Returns stack item count */
extern unsigned long
stack_count(const struct stack *);
#endif
The corresponding source file would contain the implementation of all these functions. It might also contain some private (i.e. static) functions that can't be called by the module's user.
Think about all the objects that are involved in your database program. Try to code them separately into modules and try to write the modules in such a way that they can be debugged and tested separately.
Russ
bobbitts@hotmail.com
