Limit scope of #define labels

Question

What is the correct strategy to limit the scope of #define labels and avoid unwarranted token collision?

In the following configuration:

Main.c

# include "Utility_1.h"
# include "Utility_2.h"
# include "Utility_3.h"
VOID Main() { ... }

Utility_1.h

# define ZERO "Zero"
# define ONE  "One"
BOOL Utility_1(); // Uses- ZERO:"Zero" & ONE:"One"

Utility_2.h

# define ZERO '0'
# define ONE  '1'
BOOL Utility_2(); // Uses- ZERO:'0' & ONE:'1'

Utility_3.h

const UINT ZERO = 0;
const UINT ONE = 1;
BOOL Utility_3(); // Uses- ZERO:0 & ONE:1

Note: Utility _1, Utility_2 and Utility_3 have been written independently

---

Error: Macro Redefinition and Token Collision
Also, Most Worrying: Compiler does not indicate what replaced what incase of token replacement

{Edit} Note: This is meant to be a generic question so please: do not propose enum or const

i.e. What to do when: I MUST USE #define & _Please comment on my proposed solution below.. __

Answer 1

What is the correct strategy to limit the scope of #define and avoid unwarrented token collisions.

1. Avoid macros unless they are truly necessary. In C++, constant variables and inline functions can usually be used instead. They have the advantage that they are typed, and can be scoped within a namespace, class, or code block. In C, macros are needed more often, but think hard about alternatives before introducing one.

2. Use a naming convention that makes it clear which symbols are macros, and which are language-level identifiers. It's common to reserve ALL_CAPITALS names for the exclusive use of macros; if you do that, then macros can only collide with other macros. This also draws the eye towards the parts of the code that are more likely to harbour bugs.

3. Include a "pseudo-namespace" prefix on each macro name, so that macros from different libraries/modules/whatever, and macros with different purposes, are less likely to collide. So, if you're designing a dodgy library that wants to define a character constant for the digit zero, call it something like DODGY_DIGIT_ZERO. Just ZERO could mean many things, and might well clash with a zero-valued constant defined by a different dodgy library.

Answer 2

C is a structured programming language. It has its limitations. That is the very reason why object oriented systems came in 1st place. In C there seems to be no other way, then to understand what your header files's variables start with _VARIABLE notation, so that there are less chances of it getting over written.

in header file 
_ZERO 0

in regular file

ZERO 0

Answer 3

What is the correct strategy to limit the scope of #define and avoid unwarrented token collisions.

Some simple rules:

1. Keep use of preprocessor tokens down to a minimum.
   Some organizations go so far as down this road and limit preprocessor symbols to #include guards only. I don't go this far, but it is a good idea to keep preprocessor symbols down to a minimum.
   • Use enums rather than named integer constants.
   • Use const static variables rather than named floating point constants.
   • Use inline functions rather than macro functions.
   • Use typedefs rather than #defined type names.
2. Adopt a naming convention that precludes collisions.
   For example,
   • The names of preprocessor symbols must consist of capital letters and underscores only.
   • No other kinds of symbols can have a name that consists of capital letters and underscores only.

const UINT ZERO = 0; // Programmer not aware of what's inside Utility.h

First off, if the programmer isn't away of what's inside Utility.h, why did the programmer use that #include statement? Obviously that UINT came from somewhere ...

Secondly, the programmer is asking for trouble by naming a variable ZERO. Leave those all cap names for preprocessor symbols. If you follow the rules, you don't have to know what's inside Utility.h. Simply assume that Utility.h follows the rules. Make that variable's name zero.