How to avoid namespace collision in C and C++ - c++

Question

I can use using namespace directive to avoid identifier/variable name collision, but what happens when file names or library names collision happens in large projects.
In C the conventional approach is to add files recursively using #include_next directive. How can I achieve the same in C++ without using the #include_next directive and address the issue of duplicate file names among applications and shared libraries. An example, a work around the class() function in AIX math.h clashing with identifiers named "class".
/* GNU Lesser GPLv2.1 or later */
#ifndef FFMPEG_COMPAT_AIX_MATH_H
#define FFMPEG_COMPAT_AIX_MATH_H
#define class some_text
#include_next <math.h>
#undef class
#endif /* FFMPEG_COMPAT_AIX_MATH_H */
EDIT:
Can I use, for example class machine-instruction-set where the binary has to run on multiple platforms? Can there be namespace collision in such case?

Answer 1

I can use using namespace directive to avoid identifier/variable name collision
Quite to the contrary, using namespace directive introduces collisions. You resolve collisions by specifying scopes, e.g. std::vector<> vs. boost::numeric::ublas::vector<>.
... but what happens when file names or library names collision happens in large projects?
Filename collisions are easy to prevent by being systematic: organize your headers so that they mimic your namespaces, e.g. boost::numeric::ublas::vector<> comes from #include <boost/numeric/ublas/vector.hpp>. And don't pile headers and sources of different libraries in one directory, so that you can include headers with the same name using a different directory prefix, e.g. #include <lzma/version.h> vs. #include <linux/version.h>.

Answer 2

The correct way to deal with this is to setup your build environment in a way that name clashes become less likely.
Guidelines for writing libraries
For example, most third party libraries do not introduce plain files to the compiler's include path. Instead they introduce a directory that contains the files. You can increase flexibility by introducing subdirectories for different modules.
Consider the directory structure of Boost. On the top-level, Boost only introduces a single name to the include search path: The boost directory. That way, even though boost introduces a number of header filenames which are likely to clash (like array.hpp, thread.hpp, or function.hpp), they are all wrapped away in the subdirectory:
#include <boost/thread.hpp> // this is boost's header
#include "thread.hpp" // some header specific to my current project
// no name clash :)
The same concept is used for the different libraries that ship with Boost. For example, both Boost lockfree and Boost assign have a queue.hpp header. But they live in different subdirectories, so there is no clash:
#include <boost/lockfree/queue.hpp>
#include <boost/assign/std/queue.hpp> // no clash :)
To make finding the right header file easy, Boost uses the same structure for include files and namespaces: The lockfree queue lives in boost::lockfree namespace, while the functions from the assign queue header go to boost::assign. That way it is not only straightforward to find the matching namespace from an include file and vice versa, it also decreases the likelihood of namespace clashes, as a namespace clash is also likely to manifest in a physical name clash on the file layer.
You can adapt these guidelines for your own project
Don't introduce bare include files directly to the include path. Instead group them together in a directory to avoid polluting the include path with names.
Use directory trees to further structure the include files of modules inside a single library.
Try to match the physical structure with the logical structure. Filesystem include paths should resemble namespace hierarchies if possible.
This avoids most of the nameclashes in the first place. The question is what if you have to use a third-party libraries that do not follow these rules and you get a clash that is outside your control?
Guidelines for dealing with name clashes by third-party libraries
The answer is to be brutal and enforce the separation through the build environment. Reorganize the include paths by moving conflicting libraries into uniquely identifiable subdirectories to resolve physical conflicts. This is usually non-critical. Logical conflicts require patching and recompiling, which is a lot more inconvenient. But if you really run into name clashes here, it is a sure indication that at least one of the library vendors did not do their job too well and you should consider filing a bug.
Stay away from ad-hoc fixes like #include_next to fix physical clashes or preprocessor defines to fix logical clashes. They are dirty hacks and while they might solve your problem temporarily, they are very likely to come back and bite you eventually.

Answer 3

File Name Collisions
Put libraries in separate subdirectories, and set the parent directory as the search location. So instead of:
#include "zerz.h" // supposed to be from libfoo
#include "zerz.h" // supposed to be from libbar
You can do this:
#include "libfoo/zerz.h"
#include "libbar/zerz.h"
Identifier Collisions
Use the pimpl idiom to isolate the code that interacts with each library so that the conflicting identifiers aren't dragged into zillions of projects due to transitive includes.
For example, if libfoo and libbar both have a function called Frobnicate, then you want to isolate any code that depends on those libraries so that nothing else has to include those libraries' headers and thus end up with a conflict. Only the .cpp (or .c) file that actually calls Frobnicate should #include the library's header file. That prevents unintended transitive includes, which is usually how you would end up with conflicting declarations of Frobnicate being included in a single compilation unit.
The pimpl idiom is usually presented terms of C++, but you can play the same game in C. The point is to define your own API to the library in a header. Your API should have the same functionality but using names that don't conflict (e.g., by adding a unique prefix if you can't use namespaces). All code should be able to include that header without conflicts. You then provide an implementation file (.cpp or .c), which is the only file that #includes the actual library header. This implementation file essentially forwards calls of the prefixed functions to the actual library functions. All you have to do is avoid collisions in this one file, which should be doable.

Answer 4

First of all, #include_next is not standard, is a gcc extension, also supported by Clang, but I don't know if any other compilers support it.
The only way to deal with filename collisions is to properly use either #include "foo.h" or #include <foo.h>. The former is meant to be local to the current project, while the latter is used for system libraries. Usually #include "foo.h" will also search system libraries, but not the other way around.
Anyway, #include "foo.h" should start by looking in the source file directory, you can use #include "../foo.h" etc. to do relative includes. If you have filename collisions within the same project, you're going to have to use different compile flags to set different search paths (basically make subprojects).
For symbol conflicts, #define before #include is the standard way.
Of course, the best way is to take care to avoid these kind of problems in the first place.

Answer 5

A useful method to use when using C includes in C++ programs is to use the following code snippet in your .h files.
#ifdef __cplusplus
extern "C" {
#endif
<your code here...>
#ifdef __cplusplus
}
#endif
This will allow your C++ objects to link with the C objects. I don't know about going the other way though, so perhaps this is a partial answer.

Answer 6

"I can use using namespace directive to avoid identifier/variable name collision": Nope! You should avoid using that directive in order to avoid name collisions.