module - C - properly partitioning the code into multiple files -

i'm writing program in c , i'm separating parts in different .c files (modules).

some modules (say b , c) include same module (say a) , when these modules (b , c) included module (say d), diamond "hierarchy" formed causes redefinition problems.

eg.

vec3.c

#include <math.h>  typedef struct {     float x, y, z; } vec3;  float dot(vec3 v1, vec3 v2) {     return v1.x*v2.x + v1.y*v2.y + v1.z*v2.z; }  /* ... other stuff ... */ 

ray.c

#include "vec3.c"  typedef struct {     vec3 a, b; } ray;  vec3 origin(ray r) {     return r.a; }  /* ... other stuff ... */ 

sphere.c

#include "ray.c"  typedef struct {     float t;     vec3 p;     vec3 n; } record;  typedef struct {     vec3 center;     float radius; } sphere;  typedef enum {false, true} bool;  bool hit_sphere(sphere s, ray r, float tmin, float tmax, record *rec) {     /* ... stuff ... */ }  /* ... other stuff ... */ 

camera.c

#include "ray.c"  typedef struct {     vec3 origin;     vec3 lower_left_corner;     vec3 horizontal;     vec3 vertical; } camera;  /* ... other stuff ... */  vec3 origin = {0.0, 0.0, 0.0}; vec3 lower_left_corner = {-2.0, -1.0, -1.0}; vec3 horizontal = {4.0, 0.0, 0.0}; vec3 vertical = {0.0, 2.0, 0.0};  camera cam = {origin, lower_left_corner, horizontal, vertical}; 

main.c

#include <stdio.h> #include <float.h> #include "sphere.c" #include "camera.c"  /* ... other stuff ... */  int main() {     /* ... stuff ... */ } 

in case problem arises because both camera.c , sphere.c include ray.c (and hence vec3.c), there double definition of structures , functions defined in these modules.

how can rearrange code not have these problems?

thanks!

the no language-defined rule file organization. actually, files included source file form so-called "compilation unit" created precompiler, , treated compiler single file. precompiler's directive #include literally that... includes other file current file being processed. essential ensure files included once.

a classic way use #ifndef directive of preprocessor. compilers support directive #pragma once not standart tool, behaves unpredictably in case of circular includes.

it accepted practice call files contain reusable declarations , definitions "headers" , give them .h (and .hpp sometimes). c++ standard headers agreed not have extension @ avoid mixing them c headers. e.g. stdio.h superceded cstdio , former shouldn't used in c++. there requrement include large repetetive definitions, can different extensions .inc, .incl , etc.

so why people "never include .c files". it's related toolchain used, set of utilities control application's building process. never run compiler manually. there building tool decides file , basing decision on extension. .c files considered represent separate compilation modules, tool run compiler each of them, before trying link them together.

headers should not define objects such functions or variables, can declare them external linking. why? if include header file defined variable several compilation units, you'll error linker, because units contain same symbol. so, definition should unique or program considered ill-formed. functions assumed have external linking default

/* myheader.h */ #ifndef ___myheader_h #define ___myheader_h  extern int globalvariable;  typedef struct mytype {  };  int foo(mytype);  #endif  /* myheader.cpp */ #include "myheader.h"  int globalvariable = 5;  int foo(mytype param) { /* body of foo */ } 

how files organized in project designer. if you're part of team, you're expected follow recommendations of team's lead designer or approved documentation.