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 _______________________________________________ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
