День добрый!

Помогите решить задачку или найти подход к ее решению.
В программе необходимо обеспечить высокую информативность диагностических сообщений, для быстрого поиска и устранения причин сбоя. Кто что использует?

Поделюсь своими мыслями ...
Вести просто журнал в текстовом файле ИМХО не очень удобно, так как при большом объеме информации (код ошибки, файл, строка, имя класса и функции, текст ошибки, дополнительные данные) на одну запись эта масса текста становится просто нечитабельной. Нет никакой иерархии, и две записи в журнал из одной функции могут разбежаться в стороны из-за большого кол-ва записей из вложенной функции.

Предполагаю создать свой класс для ведения лога с поддержкой иерархии, фиксацией времени. Так же планирую сделать небольшое приложение для чтения лога  и естественно поиска с фильтрацией записей по признакам.

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

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

И еще, в коде будут использоваться прерывания ... как бы все это совместить ??? пока предполагаю внутри функции всегда ставить try{}__finally{} для фиксации входа и выхода, иначе дерево в случае ошибки просто умирает (пока фиксирую родительскую запись через push в начале функции и pop в конце (в блоке __finally) - родитель всегда последний).

У кого какие мысли есть по этому поводу? Буду благодарен за любую помощь и подсказку!

Пишешь класс, допустим Log. Он ведет лог.
Пишешь дружественный класс Logger, у которого в конструктор передается ссылка на экземляр Log (можно и без этого - если экземляр Log глобальный или статический). После этого в начале каждой функции создаешь экземпляр Logger. Если произойдет исключение у Logger'а автоматически вызовется деструктор, который запишет выход из функции.
Более того, это все можно реализовать макросами, тогда есть возможность использовать __PRETTY_FUNCTION__ и прочие определения препроцессора для уменьшения кода.

вот   !

а я, значит, велосипеды пишу... только вот стандарт по поводу этого, равно как и __FUNCTION__ молчит.
Молчит и ман по g++. В гугле нашёл кое-какие сообщения в мэйл-листах, которые говорят о том, что такое таки есть и его используют. Где найти документацию?

http://gcc.gnu.org/onlinedocs/gcc/Function-Names.html

о! я уже эту страничку видел, но на другом сайте и с чуть другим оформлением, поэтому усомнился в официальности.

Респект, ну и + ты точно заслужил, спасибо 

bsa, лови и от меня .
А что думают другие компиляторы относительно __PRETTY_FUNCTION__ ? Другими словами - насколько это переносимо в пределах современных популярных компиляторов?

Про __PRETTY_FUNCTION__ не уверен, а вот, судя по той ссылке, __func__ юзать можно на любых компиляторах, совместимых с C99.

они не думают... ибо не стандарт. да и про __func__ они тоже не должны бы думать (по крайней мере в ansi iso iec 14882(2003) я такого не видел)... может пнете посмотрю )

Ммм, фишка в том, что программирую я исключительно на С++, а в С++ __func__ официально пока нету. Появится только в 2009 :(.

Добавлено через 2 минуты и 53 секунды

Нет, нет, это точно, что оффициально появится только в С++09. Я об этом даже где-то писал...




.

_Tanatos_, если сделаешь, кинь, плиз, исходники на всеобщее обозрение. Может, доделаем до состояния конфетки, если оно еще ей не будет являться  =). Было бы здорово иметь что-нибудь продуманно-универсальное для этого дела...

Добавлено через 3 минуты и 17 секунд
Ну или если кто-то знает уже готовые решения для этого, то сообщите.
По поводу боязни неуниверсальности __PRETTY_FUNCTION__ - можно использовать reflex, правда есть мысль, что здесь она через чур.... Дополнительную библиотеку все-таки подключать...

Если бы только библиотеку подключать...

в бусте есть boost/current_function.hpp 

А у меня такой вот макрос: 



Вроде работает на gcc и VCях.

_Tanatos_, я так понимаю, что ты хочешь строить дерево, в оперативной памяти, для определения причины сбоя в программе. Дерево придется периодически сохранять на диск, в идеале при добавлении нового элемента...
По хорошему лог нужно записывать так:

- должен быть простой формат лога, никаких xml и прочего, для того что-бы можно было не загружать весь файл полностью (представь что там несколько гигов), тот же xml придется парсить целиком.
- в формате лога должна быть следующая информация: код процесса, код потока, время записи, уровень(степень подробности) сообщения, дальше на твое усмотрение, можно еще номер строки и имя файла добавить..
- класс отвечающий за запись в лог(еще лучше просто функция) не должен буферизировать сообщения, иначе, если программа упадет, последние сообщения не запишутся в файл, если программа под windows, то мало просто записывать на диск данные, нужно принудительно очищать буфер файла, если этого не делать в случае вызова Terminate данные могут быть не записаны на диск
- опять-же в случае если пишешь под windows смотри MSDN на тему Event Log, ReportEvent и тд.

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

Добавлено через 1 минуту и 23 секунды
ps
недавно открыл для себя программу grep, которая очень подходит для анализа огромных лог файлов

Добавлено через 13 минут и 4 секунды
Кстати Event Log в Windows работает очень быстро, надежно, и лучше не изобретать велосипед, а использовать то, что предоставляет платформа для этих целей.

AWK подходит ещё более очень 
(на авторов, на авторов там посмотрите! )

Также посмотрите SED