Каков надлежащий “C++ путь”, чтобы сделать глобальные переменные?

Why not use the system that's already in place? That is, redirect std::clog to output to a file and write to std::clog.

std::fstream *f = new std::fstream("./my_logfile.log")

std::clog.rdbuf(f->rdbuf());

std::clog << "Line of log information" << std::endl;

Неплохая идея передать регистратор и конфигурацию всем конструкторам, если ваш регистратор и конфигурация достаточно абстрактны.

Синглтон может стать проблемой в будущем. Но это кажется правильным выбором в начале проекта. Твой выбор. Если ваш проект достаточно мал - выбирайте синглтон. Если нет - внедрение зависимости.

Я полагаю Service Locator подойдет. Что вам придется либо передавать в конструкторы, либо иметь глобально доступную статическую функцию-член в каком-то известном месте. Первый вариант гораздо предпочтительнее.

Ведение журнала относится к сфере «разделения интересов», как в аспектно-ориентированном программировании

В общем, регистрация не является функцией или задачей объекта (например, она не меняет состояние объекта; это просто механизм наблюдения / записи состояния, а вывод по существу одноразовый в большинстве контекстов) Это эфемерная и часто дополнительная функция, которая не способствует работе класса. Метод объекта может выполнять регистрацию, но регистрация может быть выполнена там, потому что это удобное место для выполнения, или когда в потоке выполнения кода есть место, где нужно записать состояние.

Поскольку C ++ не предоставляет средств для определения аспектов я склонен просто сохранять по существу внешние эфемерные объекты, такие как логгеры, глобальными и заключать их в пространство имен, чтобы их как-то содержать. Пространства имен не предназначены для сдерживания, так что это отчасти уродливо, но из-за отсутствия чего-либо еще это удобно и гораздо менее уродливо и неудобно, чем передача регистраторам формальных параметров или ссылки на них во всех объектах, которые вы хотите зарегистрировать. Это также облегчает удаление регистратора, если в какой-то момент я решаю, что он мне больше не нужен (т. Е. Если он использовался только для отладки).

Не знаю, полезно ли это в вашей ситуации или нет, но в MFC был / есть класс приложения.

Я использую, чтобы бросать подобные вещи в этот класс.

Я предполагаю, что вы не используете MFC, но если у вас есть класс приложения или что-то подобное, это может быть полезно.

Я бы избежал одноэлементного паттерна.
Слишком много проблем, когда дело доходит до тестирования и тому подобного (см. Что такого плохого в синглетах? )

Лично я передаю регистратор и т. Д. В конструктор. В качестве альтернативы вы можете использовать фабрику для создания / передачи ссылки на ресурс.

Почему бы не использовать log4cxx ? Такие проблемы давно решены и широко используются многими. Если вы не создаете какую-то совершенно особую систему ведения журналов самостоятельно ... В таком случае я бы использовал шаблон Factory, который бы создавал регистраторы для всех, кто заинтересован (или отдавал существующий экземпляр, если он синглтонный). Другие классы будут использовать фабрику для получения регистратора. Передача логгеров в параметрах конструктора - плохая идея, потому что она связывает ваш класс с логгером.

Я бы согласился с каким-то одноэлементным подходом. Вы определенно не хотите передавать объекты регистратора повсюду. Это будет очень скучно очень быстро, и IMHO - худший дизайн, чем просто наличие простого глобального объекта.

Хороший тест на то, есть ли у вас хорошее решение, - это шаги, необходимые для работы журналирования в функции, которая это нужно.

Если вам нужно сделать гораздо больше, чем

#include "Logger.h"
...
void SomeFunction()
{
    ...
    LOGERROR << "SomeFunction is broken";   
    ...
}
...

, то вы напрасно тратите усилия.

Просто передайте свой основной класс в конструктор других классов, которые вы хотите иметь доступ ко «всему»

Затем вы можете предоставить доступ к регистратору и т. Д. Через свойства члена. (Простите мой синтаксис C ++, это просто выдуманный язык под названием "C ++, запутанный VB")

например,

Class App {
     Private  m_logger;
     Private  m_config;

     Public logger() {
        return m_logger;
     }

     Public config() {
        return m_config
     }
}

Class Window1 {
     New( anApp ) {
     }
     ....
}

Почему никто не подумал о наследии и полиморфизме? Вы также можете использовать абстрактную фабрику с этим синглтоном;)