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


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

Кто выделяет и освобождает память для этих полей? 


только 256 типов сообщений? а не мало?

Ну номер строки еще ладно, но имя файла и имя ф-ии нужно указывать только при их изменении.

так он же написал, что использует Borland? а есть ли какая-нибудь портируемая вльтернатива __closure ?

присоединяюсь

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

А надо больше? Сколько не прикидывал, пока больше 10 не набиралось . Тип означает: Info, Warning, Error и аналогичное деление.
Думаю использовать более 10 уровней детализации не имеет смысла ибо ни один программист не сможет в них свободно ориентироваться.

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


А чем заменить? Если просто убрать, то указатель будет на отдельную функцию, а мне надо на функцию класса.


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

При использование __closure есть  работоспосбность кода при смене компилятора не сохранится вообще.



boost::bind + boost::function, например. 


А если мне хочется нумеровать сообщения, начиная с 0x10000000[например сообщения из .exe], а в другом месте с 0x200000[например, сообщения из .dll]? или использование юзеровских типов не предусмотрено? а почему тогда не использовать enum? 


ОпределенноХорошаяМысль.

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



Посмотрю - как разберусь исправлю. Спасибо за информацию!



Нет проблем, пользуйте m_Proc или m_Unit.
Кстати спрашивали насчет потоков ... под них так же планируется использовать m_Proc - ИМХО предостаточно.
Смысла писать туда реальный идентификатор потока не вижу, так как он от раза к разу меняется, можно его скинуть как данные при старте потока или процесса. А с логе использовать внутренние идентификаторы.


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

Тогда, на всякий случай определи его как signed char, так как стандарт этого не гарантирует по умолчанию.

И давай скорее пример использования, а то так разбираться лениво   ...

На суд уважаемых форумчан выдвигается несколько вариантов решения с вложенностью, а именно

Вариант №1: (мне нравится больше всего) вложенность управляется при помощи параметра m_Level. Его изменение производится исключительно классом TtLibLogEngine. Командой для изменения служат зарезервированные значения типа сообщения m_Type:
-1 - Увеличиваем вложенность
-2 - Уменьшаем вложенность
Плюс данного решения в том, что нет необходимости вводить дополнительные переменные, функции и т.д., минус нельзя одновременно зафиксировать запись пользовательского типа с вложенностью.
Пример использования:


Вариант №2: идентичен предыдущему варианту, но для управления вложенностью выделяется отдельные функции (можно конечно сделать и отдельный параметр, но уж больно много параметров). 
Пример использования:


Вариант №3: Вынести управление в отдельную функцию, которая будет вызываться перед регистрацией сообщения и будет модифицировать одну последующую запись. ИМХО хуже из-за лишнего вызова, хотя можно сделать с модификатором inline.
Пример использования:


--------------------

Предложение, насчет передачи имени класса и функции только один раз, отклюняю, так как:
1) Никто не мешает сделать это собственными силами. Объявляйте константы, ссылки или просто записывайте в лог один раз, а остальные записи оставляйте пустыми.
2) Как Вы себе представляете восстановление данных значений после выхода из вложенной функции???

--------------------


Принято.


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

Правильнее использовать rtti, создаешь в стеке объект, в конструкторе вызывается нужная функция(увеличивает вложенность), в деструкторе уменьшаем вложенность, а как передавать - детали. Нужно различать поток, из которого вызывается ф-я, и вычислять вложенность отдельно для каждого потока. Это можно сделать внутри TtLibLogEngine, при каждом вызове ф-ии получать ThreadId потока, и дальше вычислять для него степень вложенности.
Я зделал что то похожее, но у меня - просто надстройка над библиотекой ведения логов, которая немного форматирует текст.






Это сообщение отредактировал(а) Lazin - 26.11.2007, 15:23

Так оно и будет. Будет дополнительный класс CtLibLogHelper, который будет в конструкторе регистрировать сообщение с увеличением вложенности, а в деструкторе собщение с уменьшением вложенности.

За пример спасибо. Изучаю.

Выложи здесь реализацию данной функции?
Заранее благодарю!

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

Это сообщение отредактировал(а) Lazin - 26.11.2007, 15:26

Выкладываю предполагаемый вариант использования.
Обращаю внимание, что макросы пока не использую, дабы было понят но что есть что.
Не обращайте внимание на работу со строками, написал так для сокращения



В конструкторе класса CtLibLogHelper указываем идентификатор Процесса, потока и имя класса и функции - данные указываются один раз для одной функции. Соответственно все записи производятся через вспомогательный класс. Функция Error производит запись в журнал и сама генерирует исключение с указанным кодом (в данном случае 134).

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

Согласен. Принято к изменению. 

Попробовал - неработает!
после неудачи порылся в инете на предмет использования, вот такой пример не работает
Что делаю не так?


ИМХО лучше по старинке через флаг внутри класса и дополнительную функцию для его сброса.