include file

<global.h> : //must be include in all c file of your project but not in <global.c>

Actually it is advantageous if you do include global.h in global.c - that way the compiler can warn you of any inconsistencies!

:-)

But I don't think that simply dumping all your globals into a single file is a good idea...

<global.h> : //must be include in all c file of your project but not in <global.c>

Actually it is advantageous if you do include global.h in global.c - that way the compiler can warn you of any inconsistencies!

:-)

But I don't think that simply dumping all your globals into a single file is a good idea...

Sorry to take you to task Mr. Westermark, but I simply must disagree on the issue of "Best Practices" with respect to that type of #ifndef #define #endif usage.

I do not rely on such a methods that intrinsically asks:

#ifndef DRINK_C_COOLAID   // "Gee, did I already declare that?"
#define DRINK_C_COOLAID 9 // "I didn't?" ... "I guess I better do it now."
#endif                    // "I really hope no other file has that #define too"

The very use of this construct implies that the source code is not tightly engineered. (I consider that a bad thing).

Don't get me wrong there Per, *they* all do it that way. It is all too common in the Main Stream C world.

I don't do that construct. I like total control [and domination] over my source code (most likely due to my 'ego trouble' ;-).

Cheers,

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

I agree that you should not need to protect a #define with a conditional.

But you may have to protect a complete header file.

Let's say that it contains definitions for uint8, uint16 etc. All source files should have it. But none twice.

Just a follow-up about guard code for defines and guard code around individual symbols.

Guard code around an individual symbol may seem good, but have a big implication:

lib_header_1.h

#if !defined(MY_CONSTANT)
#define MY_CONSTANT 10
#endif

lib_header_2.h

#if !defined(MY_CONSTANT)
#define MY_CONSTANT 20
#endif

source_file_alt1.c

#include "lib_header_1.h"
#include "lib_header_2.h"
int my_data[MY_CONSTANT];

source_file_alt2.c

#include "lib_header_2.h"
#include "lib_header_1.h"
int my_data[MY_CONSTANT];

The end result will be an application that behaves differently depending on the include order of the two header files, and the developer will have no good way of figuring out why.

It is better if a library function either has a really hard limit, or is written to take the limit at run time.

But for a nother case - guarding full header files.

comlib_type_defines.h

typedef unsigned char comlib_uchar;

comlib_protocol1.h

void library1_function(comlib_uchar a);

library_protocol2.h

void library2_function(comlib_uchar a);

Now it would be nice if an end user may use either library_protocol1, or library_protocol2 or both, without having to know that the two protocol libraries have a common part with a common header file, i.e. all four examples should be allowed:

example_only_1.c

#include "comlib_protocol1.h"

...

example_only_2.c

#include "comlib_protocol2.h"

...

exampley_both_a.c

#include "comlib_protocol1.h"
#include "comlib_protocol2.h"

...

example_both_b.c

#include "comlib_protocol2.h"
#include "comlib_protocol1.h"

...

But it is important to note that comlib_protocol1.h, comlib_protocol2.h and the common file comlib_type_defines.h may not play with conditionally defined symbols. As soon as the end user is allowed to replace the value of an individual symbol, the developer got a vey big loaded gun preaimed at his/her own foot.www