чёт какая-то ерунда...

ну никаких проблем, можно посмотреть архитектуру boost.log. Там есть разные бекенды, сурсы, синки

https://github.com/SoftwareNetwork/sw/blob/master/src/sw/client/gui/logwindow.h#L10
вот у меня пример с кастомным бекендом, чтобы в гуишку лог всей программы дублировался

А причем он тут? Тут задача - переложить на юзера часть тестирования проги и нахождения в ней ошибок. Предупреждение об ошибках не должно никак влиять на работу с прогой, поскольку оно может не затрагивать критическую логику и нужно уведомлять о старых ошибках, при этом оставляя прогу работоспособной. Смотреть\отправлять\копировать удобнее всего текстовый файл, поэтому сохранять инфу об ошибках в той же бд ни разу не вариант. При этом уровень ошибки тонко зависит от от характера и степени отказа, из окна "о программе" может прилететь самая критичная ошибка, в контексте этого окна - это ошибка, в контексте всей проги - это ерунда, с прогой можно работать и дальше.

спасибо, посмотрю.

Ошибка в проге = loglevel error ну или fatal или что там тебе захочется. Зачем для этого парсить логи?

а если логов очень много, надо по ним делать аналитику, то там вплоть до субд специализированных под это есть

Не в прикладном приложении же

Если хочется аналитику — надо их собирать централизовано

ну она же идет в журнал, логируется, как о ней напомнить при следующем запуске?

Вести лог критических ошибок отдельным файлом. Условно как в апаче — error.log и ещё какой-то лог со всем остальным

хорошо, тогда мне нужно будет проверять error.log пустой он или нет. Если не пустой - выводить сообщение, если пустой - все ок. Но если он будет не пустой, то за счет того, что там только определенный левел, то мне нужно брать какую-то тулзу и объединять журналы по времени, чтобы примерно понять относимость записей с другими левелами к ошибке, а если писать туда разные левела, то это обычный журнал. Еще разделение логов усложняет работу с ними через гуи, в случае одного файла - это всего лишь одно окно, в случае нескольких - это переключатель журналов, несколько окон и т.п.  Конечно, у каждого решения есть свои плюсы и минусы, но для моего кейса в разделении логов больше минусов.

А ты не можешь одновременно писать в разные файлы с разным логлевелом?

конечно же могу. Я могу, например, каждый уровень лога писать в отдельный журнал, но как мне потом восстановить происходящее в проге, например, по времени знать, что перед ошибкой был зарепорчен вот этот info, нужно же логи как-то\чем-то объединять?

Ты не понял. Пишешь в один файл все логи, а в другой — только loglevel >= critical. Условно. Первый смотришь сам, второй показываешь пользователю ¯\_(ツ)_/¯.

Очнулись.. сначала всё что надо и не надо перевели на Электрон, ЖС и Питон.. а теперь фонд вон создать решили... лицемеры хреновы

Microsoft, Accenture и Goldman Sachs создают фонд для разработки неэнергоемкого софта

источник: forbes.ru

Почему лицемеры?

А, при чем тут Ди - в одной из работ посвящённой этой теме, Ди был на первом месте :) правда статья вроде 2018 года была...
И если смотреть тот же бенчмарк Кости, там Ди достаточно высоко, но не первый уже

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