Вложенные пространства имен, исправлены проблемы статического проектирования библиотеки.

Question

В настоящее время я нахожусь в процессе разработки довольно большой статической библиотеки, которая будет использоваться некоторыми инструментами после ее завершения.Теперь, поскольку этот проект несколько больше, чем все, чем я занимался до сих пор, я понял, что пришло время подумать о хорошей структуре для проекта.Использование пространств имен является одним из таких логических шагов.

Мой текущий подход состоит в том, чтобы разделить библиотеку на части (которые не являются автономными, но их назначение требует такого разделения).У меня есть «базовая» часть, которая теперь содержит некоторые очень распространенные определения типов и константы (используемые многими различными частями библиотеки).Другими частями являются, например, некоторые утилиты (хэш и т. Д.), Файловый ввод-вывод и т. Д.Каждая из этих частей имеет свое собственное пространство имен.Я почти закончил раздел «Утилиты» и понял, что мой подход, вероятно, не самый лучший.Проблема (если мы хотим назвать это так) состоит в том, что в пространстве имен 'utils' мне нужно что-то из пространства имен 'core', в результате чего включаются файлы заголовков core и многие директивы using.

Итак, я началдумать, что это, вероятно, нехорошая вещь и должна быть как-то изменена.Моя первая идея - использовать вложенные пространства имен, чтобы иметь что-то вроде core :: utils.Так как это потребует серьезного рефакторинга, я сначала хочу спросить здесь.Как вы думаете?Как бы вы справились с этим?Или в более общем плане: как правильно спроектировать статическую библиотеку с точки зрения пространств имен и организации кода?Если есть какие-то рекомендации или статьи по этому поводу, пожалуйста, используйте их также.Спасибо.

Примечание: я совершенно уверен, что есть более хорошие подходы, чем один.Не стесняйтесь размещать ваши идеи, предложения и т. Д. Так как я проектирую эту библиотеку, я хочу, чтобы она была действительно хорошей.Цель состоит в том, чтобы сделать его максимально чистым и БЫСТРОМ.Единственная проблема заключается в том, что мне придется интегрировать МНОГО существующего кода и реорганизовать его, что действительно будет болезненным процессом ( вздох ) - поэтому хорошая структура так важна)

Answer 1

Мой собственный подход заключается в использовании одного пространства имен на библиотеку. Я не думаю, что вложенные пространства имен приносят что-либо на вечеринку, если вы не любите печатать (на клавиатуре). Это сработало для меня без проблем.

Answer 2

Ну, я бы подумал, что в заголовке core.h есть что-то вроде

#include <string>
#include <iostream>
namespace core
{
    typedef std::string mystring;
    #define mycout std::cout
}

И не одна директива using, предотвращающая загрязнение глобального пространства имен. В заголовке utils.h вы должны использовать такие вещи, как:

#include "core.h"
namespace utils
{
    core::mystring stringfunction(core::mystring &stuff)
    {
        core::mystring result;
        // do stuff
        return result;
    }
}

Следовательно, mystring нигде нет, кроме как в core ::. Это включает в себя немного больше ввода, но для этого нужны пространства имен, позволяющие себе знать, откуда вы получаете тип / функцию / класс.

UPDATE

Другая сторона истории примерно такая:

core.h заголовок, объявляющий вещи в основном пространстве имен, как указано выше.

utils.h заголовок, объявляющий вещи в пространстве имен core :: utils, и после этого оператор namespace utils = core::utils. Это делает два подхода идентичными для пользователя и позволяет писать такие вещи, как mystring вместо core::mystring в utils*.h заголовках и *.cpp файлах.

Примерно так для utils.h:

#include "core.h"
namespace core
{
    namespace utils
    {
        mystring stringfunction(mystring &stuff)
        {
            mystring result;
            // do stuff
            return result;
        }
    }
}
namespace utils = core::utils; // allow user to type utils::stringfunction

Это немного очищает код пользователя и библиотеки.