Regarding use of modules

[Paminu]

I am trying to split my program in different parts.

I have a file called mainfile.c that contains the main() function, some
global variables and a few other functions.

I then have a file called mainfile.h that contains some structs and a list
of the functions that are used in mainfile.c

I am then trying to make another file called my_func.c that contains some
other functions that when called will update some of the global variables
defined in mainfile.c. I guess the functions that I implement here needs to
be mentioned in mainfile.h. But what about the global variables should the
not be moved from mainfile.c to mainfile.h?

[Skarmander]

Paminu wrote:

I am trying to split my program in different parts.

I have a file called mainfile.c that contains the main() function, some
global variables and a few other functions.

I then have a file called mainfile.h that contains some structs and a list
of the functions that are used in mainfile.c
No, mainfile.h should contain a list of the symbols *provided* by
mainfile.c for use by other units. Most likely, there are none. (And
it's very likely those structs you mention should be moved to other
header files too.)
I am then trying to make another file called my_func.c that contains some
other functions that when called will update some of the global variables
defined in mainfile.c.
This is not a good way of going about it. The whole problem with global
variables is that you lose all sight of where they are being used, and
in what way.
I guess the functions that I implement here needs to
be mentioned in mainfile.h. But what about the global variables should the
not be moved from mainfile.c to mainfile.h?

If you really wanted to use a global variable to be used across units,
it can be done, of course. Assuming you define it in mainfile.c, then it
should be declared in mainfile.h:

mainfile.h:
extern int global_var; /* Declare here */

mainfile.c:
int global_var = 0; /* Define here */

my_func.c:
#include "mainfile.h"

void foo() {
/* Use declared global_var */
}

But then in mainfile.c you have to be aware that global_var can be
modified by anything that includes mainfile.h. This is usually not what
you want. Either global_var can be passed and returned by functions:

mainfile.c:
int main(void) {
int local_var = ...;

local_var = foo(local_var); /* Pass by value */
bar(&local_var); /* Pass pointer ("pass by reference") */

my_func.c:
int foo(int parameter) {
/* Compute something */
return ...;
}

void bar(int* parameter) {
/* Modify directly */
*parameter = ...;
}

Or you can move the variable to the only unit it belongs to, if there is
only one:

my_func.c:
static int local_var;

void foo() {
/* Use local_var, not visible beyond my_func.c */
}

Or you can even move the variable to the only function it belongs to, if
there is only one:

void foo() {
static int local_var = 0;
/* Use local_var, is remembered across invocations of foo(), but not
visible anywhere else */
}

Using a truly global variable accessed from multiple units is a practice
that should be avoided.

Consult a good book on C; this topic will be covered.

S.

[Barry Schwarz]

On Sun, 16 Oct 2005 21:32:16 +0200, Paminu <ja******@asd.com> wrote:

I am trying to split my program in different parts.

I have a file called mainfile.c that contains the main() function, some
global variables and a few other functions.

I then have a file called mainfile.h that contains some structs and a list
of the functions that are used in mainfile.c
A header file should contain function prototypes and
type/variable/object declarations, not definitions.

I am then trying to make another file called my_func.c that contains some
other functions that when called will update some of the global variables
defined in mainfile.c. I guess the functions that I implement here needs to
be mentioned in mainfile.h. But what about the global variables should the
not be moved from mainfile.c to mainfile.h?

The global variables should still be defined in mainfile.c but should
be declared as external in mainfile.h. Prototypes for the new
functions should also be added to mainfile.h.
<<Remove the del for email>>

[Thad Smith]

Paminu wrote:

I am trying to split my program in different parts.

I have a file called mainfile.c that contains the main() function, some
global variables and a few other functions.

I then have a file called mainfile.h that contains some structs and a list
of the functions that are used in mainfile.c

I am then trying to make another file called my_func.c that contains some
other functions that when called will update some of the global variables
defined in mainfile.c. I guess the functions that I implement here needs to
be mentioned in mainfile.h. But what about the global variables should the
not be moved from mainfile.c to mainfile.h?

What you are doing is learning rules for effective modularization.

The compiler requires that all relevant information be available when a
module is compiled. When there is information which more than one
module needs, such as declarations for functions, structures, and global
variables, a recommended way to achieve this is with a header file that
is included in multiple code files as needed.

Here is how I organize my code and header files:
A code file usually contains a function or set of related functions,
such as those needed to drive an LCD. The file might be named lcd.c and
have several functions needed to control the LCD. It may have other
functions as well that are used by the various LCD routines, such as
checking LCD status. The functions that are called by other modules
have prototypes in an associated header file, lcd.h. The functions that
are only referenced internally do not have prototypes in lcd.h. They
might have prototypes in lcd.c or I may simply define the functions
before they are referenced, so that no separate prototype is unneeded.
These internal functions are declared static to prevent access from
outside the lcd module.

The header file associated with the code file (lcd.h in this example)
contains all the declarations and information needed to use lcd.c. It
literally defines the interface for those functions. This includes a
fair amount of comments preceding each function prototype. You
shouldn't need to read the code file to know what it does.

When I have global variables (which most programmers try to minimize),
they are declared in a header file, which is included by any module
referencing. It usually is declared in header file for the module most
responsible for the variable.

I sometimes have header files not associated with code files that define
project-wide parameters or types.

These rules are my requirements, beyond what is required by the
compiler, which help me organize my code for my own understanding.

The book The Pragmatic Programmer contains a recommendation called the
DRY principle -- Don't Repeat Yourself -- which means defining something
in only one place. In this case, it is the declarations of the
functions and global variables. When they are defined in only one
place, you don't have consistency problems, which can happen if
something is defined in multiple places and then changed later,
erroneously only in some, but not all places. The principle applies to
many other areas of programming, as well, such as application-related
constants.

A major challenge in programming is managing complexity. One of the
most effective techniques is good modularization. Others, of course,
will suggest additional or replacement concerns. ;-)

Thad

[Emmanuel Delahaye]

Paminu a écrit :

I am trying to split my program in different parts.

I have a file called mainfile.c that contains the main() function, some
global variables and a few other functions.
The compile unit with main() is the upper level. It may contain static
(private) functions and variables, but nothing 'exportable' (apart from
main() of course)
I then have a file called mainfile.h that contains some structs and a list
of the functions that are used in mainfile.c
Sounds like bad design.
I am then trying to make another file called my_func.c that contains some
other functions that when called will update some of the global variables
defined in mainfile.c. I guess the functions that I implement here needs to
be mentioned in mainfile.h. But what about the global variables should the
not be moved from mainfile.c to mainfile.h?

Here is a typical organisation :

/* main.c */

#include "xxx.h"

struct T
{
int dummy;
};

static void do_a(void)
{
/* ... */
}

static void do_b(struct T *p)
{
/* ... */
}

/* entry point */
int main (void)
{
struct T a;
struct xxx x;

do_a();
do_b(&a);

xxx_do_c(&x);
xxx_do_d(&x);

}

/* xxx.h */
#ifndef H_XXX
#define H_XXX

struct xxx
{
int dummy;
};

void xxx_do_c(struct xxx *self);
void xxx_do_d(struct xxx *self);

#endif /* guard */

/* xxx.c */
#include "xxx.h"

/* entry points */
void xxx_do_c(struct xxx *self)
{
/* ... */
}

void xxx_do_d(struct xxx *self)
{
/* ... */
}

And please avoid globals. I most cases, you don't need them. The design
trick is to organize the code around a data structure that holds all you
need to be of permanent duration. The code stay unique, and the data can
be instancied.

Make this your design guideline and you'll write clear, modular,
unit-testable (hence reliable) and reusable code.

--
C is a sharp tool

[Emmanuel Delahaye]

Skarmander a écrit :

If you really wanted to use a global variable to be used across units,
it can be done, of course. Assuming you define it in mainfile.c, then it
should be declared in mainfile.h:

mainfile.h:
extern int global_var; /* Declare here */

mainfile.c:
For consistency :

#include "mainfile.h"
int global_var = 0; /* Define here */

my_func.c:
#include "mainfile.h"

void foo() {
/* Use declared global_var */
}

--
C is a sharp tool

[Skarmander]

Emmanuel Delahaye wrote:

Skarmander a écrit :

If you really wanted to use a global variable to be used across units,
it can be done, of course. Assuming you define it in mainfile.c, then
it should be declared in mainfile.h:

mainfile.h:
extern int global_var; /* Declare here */

mainfile.c:

For consistency :

#include "mainfile.h"

I was saving that for the Director's Cut.

But you're right, of course. Omitting this could lead to linker errors
when you fail to keep things synchronized, or worse, it *doesn't* lead
to linker errors... if you catch my drift.

S.

[Joe Wright]

Paminu wrote:

I am trying to split my program in different parts.

I have a file called mainfile.c that contains the main() function, some
global variables and a few other functions.

I then have a file called mainfile.h that contains some structs and a list
of the functions that are used in mainfile.c

I am then trying to make another file called my_func.c that contains some
other functions that when called will update some of the global variables
defined in mainfile.c. I guess the functions that I implement here needs to
be mentioned in mainfile.h. But what about the global variables should the
not be moved from mainfile.c to mainfile.h?

Don't define objects in headers. The C header is for declaration of
information, not definitions of objects.

Assuming you program consists of two translation units, mainfile.c and
my_func.c, then create mainfile.h to be #included in both C modules. As
chief programmer, you have decided that the global variable 'int glob;'
will be defined at file scope in mainfile.c and you tell the world by
writing..

extern int glob;

...in mainfile.h.

Now because mainfile.h is included in my_func.c, glob is available
my_func and from mainfile by simply using its name.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[pete]

Thad Smith wrote:

When I have global variables (which most programmers try to minimize),
they are declared in a header file, which is included by any module
referencing.
It usually is declared in header file for the module most
responsible for the variable.

With an "extern" specifier?

--
pete