Пространства имён в C++: частые ошибки новичков

Вы написали свой begin(), а компилятор вызвал std::begin(). Или собрали проект из двух файлов, в каждом есть функция log(), и линковщик выдал multiple definition of 'log()'. Оба случая — про пространства имён. Разберём типичные грабли, на которые наступают почти все, кто начинает писать на C++, и покажем, как их обойти. Примеры проверены на GCC 13 и Clang 17, стандарт C++17 и новее.

Ошибка 1. using namespace std в заголовочном файле

Самая частая и самая заразная. В .cpp-файле using namespace std; — вопрос вкуса. В заголовке — мина замедленного действия: директива протекает во все файлы, которые подключают ваш заголовок, прямо или транзитивно.

// utils.h — так делать нельзя
#include <string>
using namespace std;   // протекает в каждый #include "utils.h"

string make_key(int id);

Теперь любой файл, подключивший utils.h, получает весь std в глобальную область. Через полгода кто-то заведёт свою функцию count или тип distance — и получит конфликт с std::count в файле, который про ваш заголовок даже не знает напрямую.

Правильно — писать полные имена в заголовке:

// utils.h — так правильно
#include <string>

std::string make_key(int id);

Правило простое: using namespace в заголовке — никогда, в области видимости функции — можно, в глобальной области .cpp — на ваш страх. Чем уже область действия using, тем меньше сюрпризов.

Ошибка 2. Функции без namespace конфликтуют между файлами

Новичок пишет вспомогательную функцию parse() в module_a.cpp и такую же parse() в module_b.cpp. Обе — с внешним связыванием¹. При линковке — multiple definition.

Три рабочих способа развести их:

• Пространство имён — обернуть каждую в свой namespace. Имена a::parse и b::parse уже не конфликтуют.
• Анонимный (безымянный) namespace — если функция нужна только внутри своего файла. Она получает внутреннее связывание, наружу не видна вовсе.
• Ключевое слово static перед функцией — старый способ дать внутреннее связывание. Работает, но анонимный namespace в современном C++ считается предпочтительным для типов и шаблонов.

// module_a.cpp
namespace {                 // анонимный namespace
    int parse(const std::string& raw) {
        return std::stoi(raw);
    }
}
// parse() виден только в этом файле, конфликта с module_b.cpp нет

Ошибка 3. ADL вызывает не ту функцию

Argument-Dependent Lookup² — механизм, из-за которого компилятор ищет функцию не только там, где вы её позвали, но и в пространствах имён её аргументов. Обычно это удобно: вы пишете std::cout << x без std::operator<<, потому что ADL находит оператор в std. Но иногда он подтягивает не ту перегрузку.

#include <iostream>
#include <utility>

namespace lib {
    struct Point { int x, y; };
    void swap(Point& a, Point& b) {   // своя swap для Point
        std::cout << "lib::swap\n";
        std::swap(a.x, b.x);
        std::swap(a.y, b.y);
    }
}

int main() {
    lib::Point p1{1, 2}, p2{3, 4};
    using std::swap;      // включаем std::swap как кандидата
    swap(p1, p2);         // ADL находит lib::swap — вызовется она
}

Это как раз работает правильно и называется идиомой using std::swap; swap(a, b); — она позволяет типу подставить свою оптимальную реализацию, а для типов без своей swap подхватить стандартную. Ошибка новичка — писать явно std::swap(p1, p2), отрезая ADL и лишая тип шанса на свою перегрузку.

Обратная ловушка: вы объявили в своём namespace функцию с таким же именем, как в std, забыли, что аргумент — стандартный тип, и ADL молча выбрал версию из std. Отлаживается это тяжело, потому что вызов внешне выглядит правильным.

Ошибка 4. Вложенные namespace без нужды и без C++17-синтаксиса

До C++17 вложенные пространства открывались лесенкой:

namespace company {
    namespace project {
        namespace detail {
            void helper();
        }
    }
}

С C++17 то же самое пишется одной строкой:

namespace company::project::detail {
    void helper();
}

Второй вариант короче и меньше шансов запутаться в закрывающих скобках. Про detail — распространённое соглашение: внутренние детали реализации, которые не входят в публичный API библиотеки. Пользователю в company::project::detail лезть не стоит, хотя технически namespace ничего не запрещает.

Ошибка 5. Псевдонимы и inline namespace не там

Длинное имя вроде company::project::detail утомляет. Псевдоним сокращает его — но только в нужной области видимости:

namespace cpd = company::project::detail;  // в .cpp — норма
cpd::helper();

В заголовке псевдоним в глобальной области — та же протечка, что и using namespace: имя cpd расползётся по всем подключившим файлам. Держите псевдонимы внутри функций или внутри собственного namespace.

inline namespace — отдельная тема для версионирования API, здесь её не разворачиваем; новичку она нужна редко и чаще ломает сборку, чем помогает.

Сводка подходов к разграничению имён

Как это ловить до того, как сломается

• Включите предупреждения: -Wall -Wextra в GCC и Clang. Часть проблем со скрытием имён (shadowing) отловит -Wshadow.
• Проверьте заголовки на using namespace и глобальные псевдонимы простым поиском по проекту — это дёшево и почти всегда что-нибудь находит.
• Для swap-подобных функций пишите идиому using std::swap; swap(a, b);, а не std::swap напрямую.
• Внутренние функции модуля кладите в анонимный namespace сразу, не дожидаясь конфликта при линковке.

Что дальше

Если ваш проект собирается компилятором с поддержкой C++20, посмотрите в сторону модулей (import/module): они решают часть проблем с протеканием имён из заголовков на уровне языка, а не соглашений. Поддержка модулей в разных сборочных системах пока неровная, так что перед переходом сверьтесь с документацией вашего компилятора и системы сборки. Ближайший практический шаг — пройтись по заголовкам проекта и убрать из них using namespace и глобальные псевдонимы, если они там есть.

¹ Внешнее связывание (external linkage) — свойство имени быть видимым из других единиц трансляции (файлов) при линковке. Обычные функции и глобальные переменные имеют его по умолчанию.

² ADL, поиск, зависящий от аргументов — компилятор при вызове функции ищет её ещё и в пространствах имён, которым принадлежат типы аргументов, а не только там, где сделан вызов.