Удобный лог не роскошь, а средство отладки, или как подключить dll при помощи h файла

[maaGames]

Примечательно, что в деструкторе синглтона не вызывается ReleaseSingletonObject.
Вторая примечательность, что ПолитикаСоздания не управляет способом создания управляемого объекта (он всегда создаётся через new), но подгружает библиотеку («в нашем случае»).
Ну и заголовок статьи не соответствует содержимому. Класс TSingleton приведён настолько не полностью, что даже не скомпилируется (не хватает класса LogFromDllPolicy или его интерфейса, хотя бы).

[sergestus]

Вызов ReleaseSingletonObject в деструкторе приведет к рекурсии. Политика создания это просто класс, который создает некоторый объект и возвращает на него некоторый интерфейс, который потом используется приложением (в нашем случае это объект логера и интерфейс логера).
Политика создания логера путем загрузки его из dll, построена таким образом, что она пытается загрузить объект логера из dll, а если этого не получается, то создает логер, который использует стандартный windows log.
TSingleton это просто шаблонный класс, который делает из класса на входе объект синглтона.
Полный код с работающими примерами можно посмотреть тут.

[maaGames]

Код не смотрел. ReleaseSingletonObject предлагается вызывать вручную? Чтоб будет, если ошибка возникнет после вызова ReleaseSingletonObject, когда синглотон уже разрушен (ответ я знаю, потому что delete вижу, а обнуления не вижу, следовательно будет Большой Барабум)?
Почему я сразу обратил внимание на деструктор? Потому что есть куча глобальных и статических объектов (Плохо? Но такова жизнь, они всегда есть в более-менее крупном проекте, те же синглтоноуправляемые объекты, помимо этого логера). В каком порядке они удаляются? Они удаляются до или после вызова ReleaseSingletonObject? Это риторические вопросы, чтобы вы подумали над усовершенствованием механизма удаления.

> Политика создания это просто класс, который создает некоторый объект и возвращает на него некоторый интерфейс
Это-то понятно. Только параметризировать синглтон следовало бы политикой создания этого синглтона (управляемого объекта, если точнее), но это уже дело привычки и зашоренного статьями Александреску взгляда. А вот к первому абзацу комментария отнеситесь серьёзно.

[sergestus]

До Большого Барабума лучше не допускать:

if(instance)
{
delete instance;
instance = NULL;
}

> Потому что есть куча глобальных и статических объектов (Плохо? Но такова жизнь, они всегда есть в более-менее крупном проекте, те же синглтоноуправляемые объекты, помимо этого логера). В каком порядке они удаляются? Они удаляются до или после вызова ReleaseSingletonObject? Это риторические вопросы, чтобы вы подумали над усовершенствованием механизма удаления.

Единственное, что приходит в голову, это постановка и снятие клиентов лога на учет, но не хочется усложнять…

[maaGames]

Другое дело, теперь хотя бы не упадёт, пусть и ценой потенциальных утечек и не разлоченных ресурсов.)

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

[Door]

всё-таки заголовок статьи странноват, да и в один .h файл можно всё что угодно запихнуть.

NamedMutexObject mutex( CreatePolicy::GetMutexName() );

Какой-то странный мютекс. Обычно принято lock() делать. И, если это делается где-то неявно, то имя совсем не подходит реальности.

cl.exe example.cpp

Зачем? Ничего же не получится.

[sergestus]

Попробуйте в h файле инстанционировать переменную, поле этого заголовок перестанет быть странным. В конструкторе мьютекса lock, в деструкторе unlock. Компиляция приведенного примера в командной строке демонстрирует, что для включения библиотеки
в проект нужно включить только h файл. Выше привел ссылку на библиотеку с рабочими примерами.

[beemaster]

Я просто oставлю это здесь

[Clash]

virtual void Log( unsigned int messageId, char *fmt,… ) = 0;

У меня для вас плохие новости