namespaces and header guards with naming conflicts

C++ has namespaces to prevent collisions of things with the same name.

Header guards serve a different purpose. They prevent includeing the same header twice. However, they can suffer from the same problem: what if two header guards from different files use the same popular name? What if there are two libraries that have a LinkedList class:

#ifndef LinkedList_H
#define LinkedList_H

// stuff


Why are those two means to uniquely identify code so different?
It’s like one sophisticated language feature on one side and some macro contraption with an arbitrary string on the other.
Why are naming conflicts not a problem for header guards? Shouldn’t the namespace be part of the header guard, to make it as unique as the namespace, so that it not only prevents duplicated include but also naming conflicts?


One method I use is to build a more complex macro name that has a practically zero chance of colliding with other names. This could be built from the following components:

  • Project name
  • Namespace name
  • File name
  • Random number or GUID


#define ...

Overkill? Yes. Easy to do? Yes. Has such an infinitesimally small chance of a collision that I can write and forget about it? Yes.


Header guards are not as sophisticated as namespaces because they are part of the preprocessor (like headers themselves), and the preprocessor is an extremely primitive part of C++, inherited from C.

A common convention is to add a project and in-project path as a prefix, e.g.


It’s not the only one of course.

#pragma once

Really, it supported by all major compillers (preprocessors). Some projects moves to use it: Qt Creator for example. Yes, it is non-standard.

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *