Плох тот Сишник что не писал свой логгер 8)

Вопрос прост: чем логируете в приложении?

Я в свое время пробывал:
log4cxx, log4cpp, boost::logging, Pantheios, чета от мозиллы...

Но в целом не нашел ничего чтобы удовлетворяло следующим условиям:
1) нативная поддержка wchar_t-шных типов
2) прозрачное логирование в unicode-е ansi данных (конвертация)
3) потокобезопасность
4) безопасность выполнения (очень неприятно один раз попал на AcccessViolation уже не помню в каком логгере при событи "места на диске нету")
5) быстрота
6) небольшая (много и не надо) настраиваемость вида выводимого лога
7) малые (а лучше без них) утечки памяти и ресурсов во время работы
8) логирование стандартных эксепшенов (std::exception) и\или возможность написать свою систему распечатки определенных exception-ов
9) поддержка больших файлов (более 2^32 байт)
...


Посоветуйте пжлст.

boost::logging
удобная, не монструозная, не перегруженная.

но недавно, после появления boost.property_tree,  подумал написать обертку, чтоб лог велся в формате JSON. очень удобно.
иногда бывает необходимо анализировать лог. и приходится писать парсеры.

Это сообщение отредактировал(а) boostcoder - 13.4.2010, 22:43

Пользуюсь своими поделками.

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

удовлетворены. А вот нафик логгеру кодировки прикручивать не ясно... Еще не ясно, откуда должны появиться утечки памяти и почему он может тормозить больше, чем устройство вывода. Эксепшенами традиционно не пользуюсь.

boostcoder, анализом можно и без json заниматься (LogParser от мелгомягких неплох http://www.microsoft.com/downloads/details...b2-f8d975cf8c07 , ну и вообще много можно найти подобного)....

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

стандартные эксепшены идут в ansi например, также многие библиотеки упорно любят ansi, а я вот предпочитаю unicode в проекте использовать... уж больно надоели эти "C:\document and settungs\Âàñÿ\" и т.д.

поверьте, может

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

jonie, странно это все очень, никогда не возникало никаких заморочек. И проекты вроде бы немаленькие были... Может быть просто стоит систему логов использовать по прямому назначению, а не в писькоизмерительных тестах?

>стандартные эксепшены идут в ansi например,..

Сам пользуюсь исключительно utf-8 и при этом нет никаких проблем с char-строками. Или внешняя библиотека выдает что-то по-русски в однобайтовой кодировке? Ну так это не проблема логгера, просто нужно сделать промежуточную перекодировку. Смысл использования wchar не раскрыт. Алсо, содрал с википедии, потому что лень искать более авторитетные источники:



>поверьте, может

В реальной жизни с прямыми руками - нет, поверьте. Сферических программистов, использующих логгеры в вакууме не рассматриваем.

>в случае многопоточного вывода...

В общем случае, если отбросить нюансы: мало потоков - блокировка, много - очередь. Тормоза? Если 256 тысяч сообщений в секунду класть, то несомненно, но этот случай лучше оставьте для того авторитетного издания, а сами welcome to real life.

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

Я предпочитаю OutputDebugString или qDebug, т.к. без отладчика или программы просмотра отладочного вывода (типа DebugView) фактически не выполняется (не кушает процессор/винчестер), соответственно не нужно ifdef'ов

использую рукоблудный. 

требования сравнимы с этими:

использую boost::logging так, как есть всё, что хотят  mrbrooks и djamshud,
правда насчёт последнего пунктика не уверен - не проверял.
P.S. жаль что в boost не вошёл.

в планах посмотреть boost::log, который, вродь, на следующий релиз утвердили + плюс
щас разбираюсь с Pantheios - нравится мне её автор. Правда мне не очень нравится
дизайн Pantheios, но может плохо разобрался, хотя Уилсон всегда на скорость давил...


Это сообщение отредактировал(а) SenkraD - 14.4.2010, 10:03

Использую либо log4cpp, либо самописную лабуду. В зависимости от требований к логгеру.

зависит от требований проекта, вообще стараюсь по возможности избегать сторонних библиотек, так что в основном самописный.

log4cxx, версия 0.10.0. В отличие от 0.9.7, он с работает с юникодом в путях к файлам.
Есть; при построении библиотеки надо указать соответствующую настройку.
Тоже есть. Сам проверял.
Настраивается (см. справку к программе).
Память не течет (не помню, чем проверял; кажется Windows-овскими средствами, что в MSDN прочитал).

Про остальное с уверенностью сказать не могу.

Небольшой оффтопик. Кто-нибудь знает хорошую документацию, желательно на русском языке для boost::logging? Или все пользуются инфой с оффициального сайта? Хочу ее попробовать, но лениво в нем разбираться.
Что меня касается, то пользуюсь .

взял буст лог, веселья ради передал в ansi логгер wchar_t* строку, распечатал адрес строки... "Да, это правильно" - скажут многие, но на мой взгляд это далеко не то поведение, которое должно быть в простом логгере.....