Здравствуйте, Ikemefula, Вы писали:

I>Лог это как раз пример того, что не должно быть синглтоном

плохой пример, тоесть понятно дело вызов логирования — это как правило либо функция, либо обьект с деструктором, либо макрос поверх чего-то этого, но в любом случае эта функция или деструктор этого обьекта будет обращаться к какому-то глобальному обьекту(банально хендл файла к примеру куда пишется).

Здравствуйте, minorlogic, Вы писали:

M>Вреден ровно настолько насколько глобальные данные.

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

Здравствуйте, Centaur, Вы писали:

K>>2. Синглтон является расширением рантайма, частью машины которая исполняет нашу программу. (Например — отладочное (!) логирование)

C>Это сегодня программа однопоточная, и отладочное логирование можно сделать синглтоном. А завтра появится новый поток, и привет. Пользоваться из двух потоков одним отладочным логом без синхронизации — портить лог. Городить синхронизацию — а нафиг тогда потоки? Остаётся только делать по отдельному логу на каждый поток.

1) Вообще любой из этих вариантов (а так же более сложные) можно спрятать внутрь синглтона. Хотя функциональный интерфейс по мне так удобнее.
2) При переделке однопоточной программы в многопоточную будет куча куда более серьезных проблем, чем доступ к логу

Здравствуйте, minorlogic, Вы писали:

А>>После того, как узнал про этот паттерн, постоянно хочется его применять ... Насколько "неправильной" для дизайна больших приложений может быть такая практика?

M>Вреден ровно настолько насколько глобальные данные.

Хуже. В отношении глобальных данных не возникает желания выделенного

Здравствуйте, Тот кто сидит в пруду, Вы писали:

ТКС>1) Вообще любой из этих вариантов (а так же более сложные) можно спрятать внутрь синглтона.
согласен, сделать синглтон потокобезопасным, добавив в его методы лок\анлок мютекса.

Здравствуйте, Sni4ok, Вы писали:

S>Здравствуйте, Ikemefula, Вы писали:

I>>Лог это как раз пример того, что не должно быть синглтоном

S>плохой пример, тоесть понятно дело вызов логирования — это как правило либо функция, либо обьект с деструктором, либо макрос поверх чего-то этого, но в любом случае эта функция или деструктор этого обьекта будет обращаться к какому-то глобальному обьекту(банально хендл файла к примеру куда пишется).

Логи могут писаться в разные файлы на разных дисках. В разные БД и таблицы, включая удаленные сервера с выбором наименее загруженного сервера. Логи могут посылаться по сети через разные соединения и еще куча всяких примеров, как может быть организовано логирование. Вообще, ИМХО, система логирования должна гибко настраиваться в конфигурационных фалайх

Здравствуйте, Sni4ok, Вы писали:

I>>Лог это как раз пример того, что не должно быть синглтоном

S>плохой пример, тоесть понятно дело вызов логирования — это как правило либо функция, либо обьект с деструктором, либо макрос поверх чего-то этого, но в любом случае эта функция или деструктор этого обьекта будет обращаться к какому-то глобальному обьекту(банально хендл файла к примеру куда пишется).

А надо будет тебе лог какого объекта перенаправть для отладки например на экран, что будешь делать ?

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Sni4ok, Вы писали:

I>>>Лог это как раз пример того, что не должно быть синглтоном

S>>плохой пример, тоесть понятно дело вызов логирования — это как правило либо функция, либо обьект с деструктором, либо макрос поверх чего-то этого, но в любом случае эта функция или деструктор этого обьекта будет обращаться к какому-то глобальному обьекту(банально хендл файла к примеру куда пишется).

I>А надо будет тебе лог какого объекта перенаправть для отладки например на экран, что будешь делать ?

А в чем проблема? Напишу класс LogToScreen, зарегистрирую его в системе логирования и дальше буду получать интересующие меня сообщения на экран... Объеты, которые пишут в лог, никак при этом не изменятся.

Здравствуйте, enji, Вы писали:

I>>А надо будет тебе лог какого объекта перенаправть для отладки например на экран, что будешь делать ?

E>А в чем проблема? Напишу класс LogToScreen, зарегистрирую его в системе логирования и дальше буду получать интересующие меня сообщения на экран... Объеты, которые пишут в лог, никак при этом не изменятся.

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

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, enji, Вы писали:

I>>>А надо будет тебе лог какого объекта перенаправть для отладки например на экран, что будешь делать ?

E>>А в чем проблема? Напишу класс LogToScreen, зарегистрирую его в системе логирования и дальше буду получать интересующие меня сообщения на экран... Объеты, которые пишут в лог, никак при этом не изменятся.

I>Проблема в том, что класс получается зависимым от системы логирования.

А как иначе? Код, который что-то логирует, безусловно зависит от системы логиривания. Класс, который сохраняет сообщения лога куда-либо, так же зависит от системы логирования.

Фишка системы логирования в том, что первый не зависит от вторых, а также в том, что вторых может быть много, они могут подключаться\отключаться динамически и т.д.

Однако обработчики лог-сообщений надо где-то регистрировать и вызываться в случае появления очередного сообщения. Вот тут и нужны какие-то глобальные данные, вероятно завернутые в синглтон. Этот синглтон может быть скрыт в реализации системы логирования и не виден никому, однако он всяко будет...

Здравствуйте, DIMEDROLL, Вы писали:

ТКС>>1) Вообще любой из этих вариантов (а так же более сложные) можно спрятать внутрь синглтона.
DIM>согласен, сделать синглтон потокобезопасным, добавив в его методы лок\анлок мютекса.

Не обязательно, можно через синглтон организовать доступ к нескольким логам, по одному на нить — если кому-то вдруг такое понадобится.

E>Ну т.е. monostate — это исключительно обертка над синглетоном.
нет, это разные концепции
синглтон однозначно связывает тип с единственным его экземпляром. Стейт однозначно связывается с поведением.
Моностейт разделяет состояние и поведение.

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

как к примеру выглядит запись в лог в контексте какого-то класса
вариант с синглтоном

class MyClass
{
  void Log(PCWSTR message)
    {
       std::wstringstream ss;
         ss << //пишем контекст this
         ss << message;
         Logger::Instance().Write(ss.str());
    }
    
    void Meth()
    {
      Log(L"Entering meth...");
        ....
    }
}

очевидный минус — мы слегка изгадили дизайн, возложив на MyClass логирование
используя моностейт этот недостаток можно исправить

class MyClassLogger: public Logger
{
   void operator()(MyClass* ctx, PCWSTR message)
     {
       std::wstringstream ss;
         ss << //пишем контекст ctx
         ss << message;
         Write(ss.str());
      }
}

class MyClass
{
  MyClassLogger log;
    void Meth()
    {
      log(this, L"Entering meth...");
        ....
    }
}

Здравствуйте, Тот кто сидит в пруду, Вы писали:

ТКС>Не обязательно, можно через синглтон организовать доступ к нескольким логам, по одному на нить — если кому-то вдруг такое понадобится.
Как?
В методе write() определять ID потока и писать в соответствующий потоку файл?

Здравствуйте, DIMEDROLL, Вы писали:

ТКС>>Не обязательно, можно через синглтон организовать доступ к нескольким логам, по одному на нить — если кому-то вдруг такое понадобится.
DIM>Как?
DIM>В методе write() определять ID потока и писать в соответствующий потоку файл?

Можно так, можно с помощью TLS (например, boost::thread_specific_ptr) разрулить.
А вообще, идея с несколькими файлами лога мне не нравится. По-хорошему надо бы просто завести по буферу на поток, чтобы не терять много на синхронизации, из которых потом (когда наберется цельная запись лога) асинхронно (overlapped I/O) сбрасывать все в один файл.

Здравствуйте, Аноним, Вы писали:

А>После того, как узнал про этот паттерн, постоянно хочется его применять . Кажется очень удобным иметь под рукой объект, в любом месте программы. То есть, и код структурируется по классам, и не нужно с передачей ссылок на объекты возиться. Но вот в "настоящих" ООП приложениях практически не встречаю его (обычно синглтоны — только объекты Application в различных фреймворках). До этого писал на С. Насколько "неправильной" для дизайна больших приложений может быть такая практика?

Синглетон — очень удобная штука, просто легко забыть что именно он из себя представляет и
использовать его не по назначению. А еще это многие сотни или тысячи extern-ов, которые
теперь не нужно включать во все исходные файлы, где синглетон используется, как это было
бы в случае с глобальными объектами. И временем жизни данного объекта тоже можно
управлять (вспоминается синглетон-феникс), чего о глобальных объектах не скажешь.
Кстати, упорядоченность инициализации/разрушения глобальных и статических объектов — это
общая проблема проектирования, присущая не только синглетонам.

В среде, где я работаю, принято простые объекты-синглетоны переопределять специальным образом:

typedef Singleton<CService, ThreadingModel<Multi> > S_Service;

или даже

#define S_ServiceState Singleton<CService, ThreadingModel<Multi> >::instance().state()

В результате имеем компактный и понятный синтаксис типа:

if (S_ServiceState != FALSE)
{
...
}

Здравствуйте, Тот кто сидит в пруду, Вы писали:

ТКС>По-хорошему надо бы просто завести по буферу на поток, чтобы не терять много на синхронизации, из которых потом (когда наберется цельная запись лога) асинхронно (overlapped I/O) сбрасывать все в один файл.

всё равно эту запись(хоть и асинхронную) вам придётся синхронизировать, да и ждать- пока наберётся нужное количество информации, чтобы записать- утопично, поскольку где гарантия что, программа не рухнет прямо через мгновение, а вы потеряете ту информацию ради которой и велось логирование?

Здравствуйте, enji, Вы писали:

I>>Проблема в том, что класс получается зависимым от системы логирования.

E>А как иначе? Код, который что-то логирует, безусловно зависит от системы логиривания. Класс, который сохраняет сообщения лога куда-либо, так же зависит от системы логирования.

Иначе — зависимость только от интерфейса для логирования а не всей системы или синглтона какого.

E>Однако обработчики лог-сообщений надо где-то регистрировать и вызываться в случае появления очередного сообщения. Вот тут и нужны какие-то глобальные данные, вероятно завернутые в синглтон. Этот синглтон может быть скрыт в реализации системы логирования и не виден никому, однако он всяко будет...

Он то будет, но сути это не меняет. Если класс зависит от какого то синглтона и тд, то во время отладки нужно подменить этот синглтон и тд и тд.

А если зависит только от интерфейса, то достаточно конкретный класс инициализировать определенным образом.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, enji, Вы писали:

I>>>А надо будет тебе лог какого объекта перенаправть для отладки например на экран, что будешь делать ?

E>>А в чем проблема? Напишу класс LogToScreen, зарегистрирую его в системе логирования и дальше буду получать интересующие меня сообщения на экран... Объеты, которые пишут в лог, никак при этом не изменятся.

I>Проблема в том, что класс получается зависимым от системы логирования.

Не факт, можно всё через конфиги зарегистрировать да и всё. Класс создаёт нужную категогрию логирования и если для неё нет отдельной настройки — она пишется в дефолтный лог, а если есть — то уже как настроят.

Здравствуйте, blackhearted, Вы писали:

I>>Проблема в том, что класс получается зависимым от системы логирования.

B>Не факт, можно всё через конфиги зарегистрировать да и всё. Класс создаёт нужную категогрию логирования и если для неё нет отдельной настройки — она пишется в дефолтный лог, а если есть — то уже как настроят.

А как можно сделать "создаёт нужную категогрию логирования " без зависимости от системы логирования ?

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, blackhearted, Вы писали:

I>>>Проблема в том, что класс получается зависимым от системы логирования.

B>>Не факт, можно всё через конфиги зарегистрировать да и всё. Класс создаёт нужную категогрию логирования и если для неё нет отдельной настройки — она пишется в дефолтный лог, а если есть — то уже как настроят.

I>А как можно сделать "создаёт нужную категогрию логирования " без зависимости от системы логирования ?

вызывая

logSingleton.createCategory("someString");

C таким подходом вообще всё логирование — это зависимость от системы логирования.