Я не очень понимаю что нужно получить в итоге, наверное лучше сначала составить какой нибудь список требований к библиотеке т.е. что нам от нее надо....
использование элипсисов я считаю тупиковым, так как в данном случае теряется гибкость и расширяемость, если я сделаю свой класс, как мне расширить класс, что-бы он выводил в лог объекты моего класса. Для этого придется наследовать, от класса - логгера, и переопределять ф-ю. Лучше сделать это так, как это сделано в библиотеках iostream или boost::serializaion etc. 
должно выглядеть примерно так:

Можно использовать интерфейс как в iostream для изменения параметров (там это называется манипуляторами)

с таким интерфейсом проще написать макросы

и так можно написать для любого кол. параметров

Это сообщение отредактировал(а) Lazin - 29.11.2007, 15:53

Переработал класс CtLibLogHelper


Примеры использования:

В результате получаем следующий лог:


Если последний вызов
    LogHelper.Post(lltInfo, __LINE__, true);
заменить на обычный
    LogHelper.Post(lltInfo, __LINE__);
получим:
[/code]
В результате получаем следующий лог:

Последняя строка сформируется автоматически.

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

Эта ветка для этого и создана .
Конечно в идеале сначала составить что-то вроде ТЗ, а потом уже писать.
Но! я давненько не программировал, так что пользуясь случаем восстанавливаю навыки.


С таким аргументом не поспоришь 
Да и возможность записать все в одну строку прильщает.
Непонятно только как добавлять вспомогательную информацию и  как разделять сообщение и данные?

Склоняюсь к использованию дополнительного класса CtLibLogHelper для управления вложенностью и запретить прямой доступ извне. Это позволит гарантировать, что иерархия будет корректной всегда. Иначе можно сделать 10 увеличений вложенности а потом по исключению (или недосмотру) словить неправильную иерархию. А сам класс CtLibLogEngine тогда будет использоваться для записи сообщений в текущий уровень.

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

Какие еще есть пожелания?

Это сообщение отредактировал(а) _Tanatos_ - 29.11.2007, 16:46

Не насилуйте va_args, юзайте boost::format...

как вариант, определить оператор << в классе LogHelper, будет более логично...
тем более LogHelper отвечает за контроль иерархии записей

А как такой вариант?

Опробовал вполне работоспособный вариант.

С макросом вообще сказка получается:


Остается правда вопрос! Как с помощью макроса при финальной компиляции исключить из кода запись в журнал?

Это сообщение отредактировал(а) _Tanatos_ - 29.11.2007, 21:07