1. в системный application event log
2. в пользователький файл
у меня в программе используется cerr, но это только на экран выводится
знаю, что есть clog, но нигде не видел никода примеров,
вы не могли бы что нибудь посоветовать, общую схему
Здравствуйте, avsokolov, Вы писали:
A>1. в системный application event log A>2. в пользователький файл
A>у меня в программе используется cerr, но это только на экран выводится A>знаю, что есть clog, но нигде не видел никода примеров, A>вы не могли бы что нибудь посоветовать, общую схему
Я бы посоветовал сконструировать обобщенную схему, которую потом можно настроить под любое конечное хранилище сообщений. Будь то event log, файл или вообще окно консоли. Либо во все три сразу.
Тут главное
— простота формирования сообщения.
— детализация сообщения.
У тебя есть приблизительное схематическое представление о том что ты хочешь получить?
У меня есть схема, которую я использую для написания тестовых программ — состоит из трех классов (интерфейсов)
— log. Хранилище сообщений
— message. Сообщение
— tracer. Класс для формирования сообщения и отсылки в log
Использование приблизительное такое
void func(t_log* log,int Arg)
{
t_tracer tracer(log,"func"/*Это типа источник сообщения*/);
tracer<<"Hello from func. Arg="<<arg<<send/*отправить сообщение*/;
}
Есть возможность (через манипуляторы) указывать категорию сообщения: ошибка, предупреждение, просто сообщение.
Исходники можешь посмореть в дистрибутиве моей игрушки (lib/structure/test_obj). Там же найдешь и примеры.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, avsokolov, Вы писали:
A>1. в системный application event log A>2. в пользователький файл
A>у меня в программе используется cerr, но это только на экран выводится A>знаю, что есть clog, но нигде не видел никода примеров, A>вы не могли бы что нибудь посоветовать, общую схему
Конечный приемник сообщений лучще инкапсулировать. Основное внимание стоит уделить конструкции для формирования сообщения. В простых случаях можно ползоваться stream-like классами и манипуляторами.
Отдельно стоит рассмотреть вопрос использования лога из разных потоков:
поток1: my_log << "в потоке 1 " << data1 << rec_end;
поток2: my_log << "в потоке 2 " << data2 << rec_end;
В результате такого кода записи могут смешаться, т.е. надо использовать синхронизацию,
например, критическую секцию. Явное задание начала и конца записи с помощью манипуляторов или функций
лога не лучший выход, т.к. легко можно забыть их написать.
Второй аспект, что лог иногда хочется полностью или частично отключить. Поэтому стоит продумать
уровень лога и способ его задания в многих местах кода, где сообщения формируются. При этом хорошо бы избавиться от выполнения кода по вычислению текста сообщения.
Я использую примерно такой класс для записи лога:
class log_record
{
public:
log_record(int log_level, ..еще что угодно..);
~log_record();
operator const void*() const; // для проверки в if template <typename T>
log_record& operator<<(const T&);
private:
...
log_record(const log_record&);
log_record& operator=(const log_record&);
};
Использовать удобно так:
if (log_record r(4, DEBUG_MESSAGE))
{
r << "Hello: ";
r << foo();
}
Функция foo выполняется только при условии, что r.operator const void*() вернет не 0.
Здравствуйте, avsokolov, Вы писали:
A>у меня в программе используется cerr, но это только на экран выводится A>знаю, что есть clog, но нигде не видел никода примеров,
std::clog и std::cerr — это одно и то же, с той лишь разницей, что первый буферизованный.
Как уже отметили другие авторы логирование лучше обобщить, так же как и авторы выше приведу общее описание используемой системы протоколирования работы программы, что бы топикастер мог оценить несколько разных реализаций и выбрать/выработать подходязий ему вариант:
Моя система протоколирования содержит несколько классов:
1. Класс "Сообщение протокола" — объект этого класса несёт в себе разнообразную информацию, такую как "тип сообщения" (уровень ошибки), имя файла и номер строки где возникла ошибка, время возникновения относительно старта программы, строка для сообщения программиста и т.д.
2. Класс "Регистратор протокола" — абстрактный класс, основной метод EventProcess. Наследник может делать с сообщением что ему надо, например записать в файл, скинуть в сеть админам, вывести на экран, в консоль, произвести какую-то другую операцию, типа автоматического сохранения данных ну и т.д.
3. Ядро протокола — принимает сообщения протокола и переправляет их регистраторам протокола, в соотвествие с настрйоками фильтров. Соотвественно ядру протокола передаются регистраторы протокла с указанием настроек фильтрации, а когда ядро протокола принимает сообщение протокола, оно бежит по списку регистраторов, проверяет соответствие сообщения фильтру, и если осотвествует то передаёт сообщение регистратору на обработку.
Так же в ядре протокла может быть реализована какая-то другая логика, например ведение собственного лог-файла, ЕСЛИ ниодного регистратора не передано (дабы сообщения не терялись между моментом создания ядра протокола и моментом когда ему укажут регистраторы), проверку того была ли программа в прошщлый раз заверщена корректно или аварийно и т.д.
---=== С наилучшими пожеланиями, Phoenics ===--- _
Здравствуйте, avsokolov, Вы писали:
A>1. в системный application event log A>2. в пользователький файл
A>у меня в программе используется cerr, но это только на экран выводится A>знаю, что есть clog, но нигде не видел никода примеров, A>вы не могли бы что нибудь посоветовать, общую схему
Есть возможность программно перенаправить вывод в clog в файл, кто-нибудь пользуется этой возможностью, какого ваше мнение?
Здравствуйте, avsokolov, Вы писали:
A>1. в системный application event log A>2. в пользователький файл
A>у меня в программе используется cerr, но это только на экран выводится A>знаю, что есть clog, но нигде не видел никода примеров, A>вы не могли бы что нибудь посоветовать, общую схему
Вести можно хоть как. Только ядро системы логирования должно быть представленно достаточно унифицированным интерфейсом, чтобы всю начинку можно было легко заменить, не заменяя при этом все выводы в лог по тексту.
Каждая запись в логе должна содержать уровень ошибки, время, текст программиста. Структура самого файла должна быть достаточно регулярной, чтобы логи можно было легко анализировать простенькими парсерами.
А вообще, сколько логов я видел, у них у всех одна проблема — это тот ужос, который туда пишут. Иногда бывает, что лог просто бесполезен из-за своей лохматости, хотя сама система логирования сделана грамотно.
Ну и еще лог должен быть перенаправляемый на разные таргеты (консоль, файл, сеть и т.д), должен быть отключаемый, должен иметь фильтры уровней сообщений, которые нужно писать в лог (например, писать только ошибки и выше).
А главное — интерфейс .
Здравствуйте, slavo, Вы писали:
S>А вообще, сколько логов я видел, у них у всех одна проблема — это тот ужос, который туда пишут. Иногда бывает, что лог просто бесполезен из-за своей лохматости, хотя сама система логирования сделана грамотно.
Сделай его древовидным
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
S>А вообще, сколько логов я видел, у них у всех одна проблема — это тот ужос, который туда пишут. Иногда бывает, что лог просто бесполезен из-за своей лохматости, хотя сама система логирования сделана грамотно.
Кстати да, я тож почти не видел удобно читаемых логов. Поэтому например сам вывожу основной лог в html таблицу, раскрашивая сообщения в соответствие с css-таблицей стилей. Например ошибки выделяются класным, варнинги жёлтым и т.д. Лог достаточно удобно читается, даже если большой, всё важное выхватывается беглым взгядом.
---=== С наилучшими пожеланиями, Phoenics ===--- _
Здравствуйте, avsokolov, Вы писали:
A>1. в системный application event log A>2. в пользователький файл
A>у меня в программе используется cerr, но это только на экран выводится A>знаю, что есть clog, но нигде не видел никода примеров, A>вы не могли бы что нибудь посоветовать, общую схему
общая схема — интерфейс логгера должен быть максимально простым
что-то типа log.Write(message)
куда оно на самом деле пишется, определяется приемниками (sinks),
т.е. файл, буфер в памяти, консоль, и т.д.
в сложных приложениях обычно все это конфигурится через XML, какие приемники подключать
базовые функции логгера обычно включают:
-фиксация времени
-фильтры (фильтрация сообщений по критериям)
-форматирование (подключение пользовательских объектов-форматтеров сообщений)
-уровень детализации (verbose) — с какой глубиной детализации логировать,
например уровень 0 — только статус выполнения высокоуровневых бизнес-функций , а уровень 999 — вплоть до кодов возврата из системного API
(или наоборот)
файловые приемники так же могут иметь функцию "ротации" (автоподчищения), например лог занимает 99 файлов,
и по достижении этого числа удаляет самый старый.
также могут быть подключены объекты-триггеры (или таймеры), инициирующие событие закрытия файла и открытия нового —
например по времени, по числу сообщений, по размеру, или по принципу "первое наступившее" из всех перечисленных событий
Тебе уже дали много советов по поводу системы логирования
В качестве практического примера можешь посмотреть на log4cpp (Apache Project)
Это логер со всеми перечисленными ранее свойствами
Единственная трабла с этим логером заключалась раньше в том, что архив, который можно было скачать с сайта
был не последним релизом и содержал ошибки (в MSVC были утечки памяти при использовании логера), поэтому надо было
качать исходники из репозитория с исходниками (то ли CVS, то ли SVN). Посмотри это лучше на сайте логера ...
Удачи!
Здравствуйте, Phoenics, Вы писали:
S>>А вообще, сколько логов я видел, у них у всех одна проблема — это тот ужос, который туда пишут. Иногда бывает, что лог просто бесполезен из-за своей лохматости, хотя сама система логирования сделана грамотно.
P>Кстати да, я тож почти не видел удобно читаемых логов. Поэтому например сам вывожу основной лог в html таблицу, раскрашивая сообщения в соответствие с css-таблицей стилей. Например ошибки выделяются класным, варнинги жёлтым и т.д. Лог достаточно удобно читается, даже если большой, всё важное выхватывается беглым взгядом.
Это да, удобно. Я написал себе парсер, который по разным правилам раскрашивает лог. И тоже взлядом быстро нахожу ошибки. Проблема только в том, что когда программистов в команде много, то каждый считает свою ошибку не просто ошибкой, а мега фатальной ошибкой, приоритет которой наиважнейший. Или наоборот всё подряд валят с самым низким приоритетов. Тут уж хоть раскрашивай, хоть не раскрашивай.
_
.
