Re: unique identifiers for guard macros

[Bernd Strieder]

Hello,

Angel Tsankov wrote:

> You needn't be sorry for asking - I just had to be more specific, I
> guess. In a large project it is possible to have duplicate file names
> in different folders (and in different namespaces). This is why it is
> better to have some other way to form the guard.

If you have several header files with the same names, then you will get
into trouble if they get used together, anyway. The compiler has to
search them according to its path settings, and will always find only
one of them. It is possible to get away with some tricks, e.g.
including path components in #include, but this is a burden for
maintainability.

After renaming the header files the project is clear again, the
different headers can be used together, and the standard include guard
heuristic continues to work.

A related story: The code of a C++ project was transferred to a
case-insensitive filesystem. One of its header files is called
"String.h" capital S. When processing #include <string>, somewhere in
the system headers there is #include "string.h", and since user defined
paths are searched before system paths, the compiler took the String.h
of the project for system string.h, which triggered errors nobody had
ever seen before. 

The C++ standard does not talk about organizing code into files. There
are terms like translation unit, and descriptions of the effects of
some #include. We have namespaces to overcome collisions in the code
itself, but there is nothing to rely on when talking about files
containing the code, nothing to resolve filename collisions. It's
completely up to the programmer to handle this.

Bernd Strieder