Благодарю всех за активное участие и ценные советы.

В силу обстоятельств на начальной стадии проекта буду писать на C++ Builder а он не знает не __func__, __FUNCTION__ и __PRETTY_FUNCTION__. Ну да ладно, меня не ломает скопировать название функции и класса, и потом можно написать простую тулзу которая перебирая перед компиляцией все исходники будет править имя класса и функции - так что это решаемо.

Отказаться от использования ООП думаю не оправданно. Конечно остаются некоторые вероятности, но отказать может почти все. Например от отключения питания не спасут никакие технологии программирования (кстати ИБП тоже подыхают периодически).

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

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

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

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

Это сообщение отредактировал(а) _Tanatos_ - 21.11.2007, 11:20

О чем то похожем говорил bsa, можно вынести часть функционала в отдельный класс и использовать raii



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


Это сообщение отредактировал(а) Lazin - 21.11.2007, 11:55

Я бы ещё добавил

А вот, кстати, содержимое boost/current_function.hpp:

Все весьма банально =)

он знает __FUNC__. 

* ушёл смотреть *

ну вот, уже выложили 
ну так, в принципе, и предполагалось.

Буст подруливает.
Maykу однозначно плюс.

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

структура FILETIME, функции GetLocalTyme SystemTimeToFileTime

А что, в <ctime> большой выбор для этого?    Или что-то нестандартное хочешь использовать? Время события системное хочешь использовать, или считая от запуска программы?

bsa, он написал очень хороший пример

всем, кто пытается осмыслить посты StarikansBack'а - этот убогий является каким-то обгашенным куском недоразума, генерирующим случайные наборы слов.

Кстати пример кода взят из одного из недавних постов на форуме))

точнее множество его клонов))

Вот что у меня получилось на данный момент 
Привожу фрагмент кода с описанием структуры данных одной записи:



Какие есть мысли и соображения?
Изначально буду реализовывать функцию регистрации записи с полным перечнем 
Поля m_Level и m_Time обрабатываются автоматически внутри класса.
Предполагаю, что использование полей m_Type, m_File и m_Line будет внутри макроса, тем самым сократиться общая длина записи
Макрос __FUNC__ пока не буду использовать, так как нет гарантий, что при смене компилятора работоспособность кода сохранится.
Для времени пока остановился на SYSTEMTIME, дабы не вызывать лишние функции преобразования, да и при записи в текстовый файл не надо будетзаниматься обратной конвертацией для форматирования.

далее приведено определение обработчика для регистрации новой записи


Вот и сам класс журналирования


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

примерно так.
Вспомогательный класс опишу чуть позже.

Поддержка многопоточности на последний этап, так как это на перспективу и мне пока не нужно.

Из актуальных вопросов это регистрация условий обработки - ограничение по минимальному и максимальному уровню для m_Type для каждого отдельного m_UnitID, что позволит сократить объем сохраняемых записей.

Пока планирую сделать так:


Соответственно делаем массив таких записей и при регистрации новой записи сначала пробегаемся по этому массиву и проверяем на выполнимость условий, если разрешающего условия не найдено, то завершаем обработку, иначе поочередно вызываем все обработчики.

При необходимости задавать условия для каждого обработчика отдельно, это уже реализуется внутри конкретного обработчика.

Какие есть мысли, пожелания, предложения?
По ходу дела буду выкладывать готовые фрагменты и по результату скину все целиком.

Это сообщение отредактировал(а) _Tanatos_ - 23.11.2007, 14:27

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