Сравнение библиотек логирования

Не, ну это ни о чем. То-то я смотрю по вашим тестам асинхронный g3log наравне с синхронными логгерами. Там flush policy по умолчанию = 1.

Спасибо, скорость в моем нынешнем проекте не так важна. Буду использовать Boost.

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

Смысл моего этого замечания на самом деле был в том, что log4cxx (уверен, что это относится и к log4cpp/log4cplusplus) можно быть сильно, и быстро, кастомизировать под свои кейзы в случае необходимости. Конечно, такое требуется обычно раз в жизни, но обычно в тот самый момент, когда времени переходить на новый логгер точно не будет. Я, кстати, слабо представляю зачем тот же DayliRollingAppender вообще нужен, хоть и делал его. Другими словами, кастомизация логгера — это один из кейсов его использования. И если вы хотели «сравнить логеры с точки зрения их простоты использования», простота расширения log4cxx — это вообще в тему.

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

Это большой миф, что синхронное логгирование может что-то там замедлить. Объясню на примере. Мы делаем софт, который сильно грузит cpu и диск. И для нас каждый процент cpu, так же как любая задержка работы с файловой системой, очень важен. Вплоть до того, что пришлось Sleep(0.5) реализовывать, так как 1 миллисекунда для нас — это слишком большая задержка. Соответственно, постоянно профилируемся по нагрузке проца, и часто ищем задержки с помощью gpuview и других тулзовин. Так вот, синхронный логгер не даёт ни сколько нибудь значительную нагрузку на cpu, ни сколько нибудь значительных задержек работы с файловой системой. Насколько я помню, несмотрю на то, что пишет он синхронно в файл, то сам файл по дефолту флашится на диск сразу после записи только при ERROR/FATAL. А так собственно есть буферизация в винде, по умолчанию винда скидывает данные на диск большими блоками (аля секторами), что очень эффективно. В синтетических тестах может и есть какая-то разница с асинхронными логгерами, а вот в реальных приложениях — нету.

Перехват падений в этом случае решает проблему, можно даже стэк распечатать или сохранить краш дамп — самый простой способ найти и исправить дефект в разумные сроки.

Вы зря путаете логгирование и перехват исключений. Одно другое никак не заменяет. А случаев, когда партнёр, находясь в 300 км от ближайшего интернета, по телефону зачитывает логи модуля, который падает, за неимением возможности выслать даже минимальные дампы, в моей практике было не один, не пять, и даже не 10. Кстати, как показала практика — распечатывание стека при падении в самом падающем приложении — тоже не состоятельная идея (применительно к Винде). Там куча проблем, которые надо решать. Например, либо символы в бинари встраивать (C7), увеличивая их размер в разы, а то и в десятки раз, либо всё-таки старая добрая pdb и раскрутка стека на машине разработчика. Или ещё например, что бы записать в файл, когда закончилась память (выжрали 4 гига, и new постоянно кидает bad_alloc), тоже надо постараться, так как даже fopen пытаться выделить некие буффера, и если памяти реально не осталось, то даже это сделать не получится, и том чтобы использовать ofstream разговор вообще уже не идёт (если что я знаю как такую проблему решать, я к тому, что это всё не тривиально).

Утилита стоит денег если используется профессионально.

Вы здесь опять суть не уловили. Дело не в том, что есть бесплатный logmx для некоммерческого использования, а в том, что для log4j/log4net/log4cxx построена огромная инфрастуктура. Тех же анализаторов логов можно за 10 минут наверное с десяток нагуглить, на любой вкус и кошелёк, всё не закачанчивается на logmx'е. Кстати, обычные логи в log4cxx настраиваются так хорошо, что обычно не требуют специализированных средств для своего анализа, обычно это бывает полезно в очень специфичных случаях.

Знаю. Используйте cmake, который вам сгенерирует Makefile для нужного компилятора, и вот эту примочку к нему, которая умеет проставлять cmake'у правильные флаги прекомпилированных заголовков, и для clang, и для gcc, и даже для visual studio.