Несколько вопросов по поводу моей компетенции и читабельности кода который я пишу
singleton<T>::instance() -- это вообще нормально? Т.е. это в порядке вещей что каждый вызов логгера сопровождаеться жутким синтаксическим оверхедом? К примеру, singleton<logger>::instance() << "Log" << endl;
Здравствуйте, Chiрset, Вы писали:
C>Несколько вопросов по поводу моей компетенции и читабельности кода который я пишу
C>singleton<T>::instance() -- это вообще нормально? Т.е. это в порядке вещей что каждый вызов логгера сопровождаеться жутким синтаксическим оверхедом? К примеру, singleton<logger>::instance() << "Log" << endl;
Здравствуйте, Chiрset, Вы писали:
C>Несколько вопросов по поводу моей компетенции и читабельности кода который я пишу
C>singleton<T>::instance() -- это вообще нормально? Т.е. это в порядке вещей что каждый вызов логгера сопровождаеться жутким синтаксическим оверхедом? К примеру, singleton<logger>::instance() << "Log" << endl;
Я бы на твоем месте перестал бы заморачиваться по мелочам.
Синтаксический оверхед -- это пугало для дилетантов
Здравствуйте, Chiрset, Вы писали:
C>Несколько вопросов по поводу моей компетенции и читабельности кода который я пишу
C>singleton<T>::instance() -- это вообще нормально? Т.е. это в порядке вещей что каждый вызов логгера сопровождаеться жутким синтаксическим оверхедом? К примеру, singleton<logger>::instance() << "Log" << endl;
Нет, не нормально. Нужно думать об удобстве собственной работы, краткости и выразительности кода. Логгер -- штука часто используемая, так что стоит сделать работу с ним удобной.
Например, с помощью глаголов.
enum LogType { Log }; // Это приём я называю глаголом.template <class T>
logger & operator << (LogType,const T &x) { return singleton<logger>::instance() << x ; }
...
Log << "Log message" << endl ;
А по поводу индусов -- все индусы, просто в разной степени.
Ш>enum LogType { Log }; // Это приём я называю глаголом.
Ш>template <class T>
Ш>logger & operator << (LogType,const T &x) { return singleton<logger>::instance() << x ; }
Ш>...
Ш>Log << "Log message" << endl ;
Ш>
+1
Ш>А по поводу индусов -- все индусы, просто в разной степени.
+1
Этот приём я никак не называю, но когда-то я писал свой лог со сложными стратегиями протоколирования и форматирования, со стратегиями многопоточности и введение подобного класса (MessageLogger) резко все улучшило, как для клиентов лога, так и в самом логе:
Здравствуйте, srggal, Вы писали:
S>Этот приём я никак не называю, но когда-то я писал свой лог со сложными стратегиями протоколирования и форматирования, со стратегиями многопоточности и введение подобного класса (MessageLogger) резко все улучшило, как для клиентов лога, так и в самом логе:
<skipped>
Я это называю Accessor Pattern. Он полезен не только для логгирования но и для ряда других задач. На нём можно сделать хорошую инфраструктуру для работы с синглетонами.
Здравствуйте, srggal, Вы писали:
S>Здравствуйте, Шахтер, Вы писали:
S>Этот приём я никак не называю, но когда-то я писал свой лог со сложными стратегиями протоколирования и форматирования, со стратегиями многопоточности и введение подобного класса (MessageLogger) резко все улучшило, как для клиентов лога, так и в самом логе:
Здравствуйте, Шахтер, Вы писали:
Ш>Здравствуйте, Chiрset, Вы писали:
C>>Несколько вопросов по поводу моей компетенции и читабельности кода который я пишу
C>>singleton<T>::instance() -- это вообще нормально? Т.е. это в порядке вещей что каждый вызов логгера сопровождаеться жутким синтаксическим оверхедом? К примеру, singleton<logger>::instance() << "Log" << endl;
Ш>Нет, не нормально. Нужно думать об удобстве собственной работы, краткости и выразительности кода. Логгер -- штука часто используемая, так что стоит сделать работу с ним удобной.
Пасему и запостил. Ш>Например, с помощью глаголов.
Спасибо
Ш>А по поводу индусов -- все индусы, просто в разной степени.
+1
S>Этот приём я никак не называю, но когда-то я писал свой лог со сложными стратегиями протоколирования и форматирования, со стратегиями многопоточности и введение подобного класса (MessageLogger) резко все улучшило, как для клиентов лога, так и в самом логе:
Недавно закончил писать свой лог, в котором также реализовал поддержку записи из нескольких потоков и уровни сообщений (Alert, Warning, Notice). Интересно было бы обсудить реализацию этих "фич" лога.
Потокобезопасность я решил реализовать через критические секции. Выглядит это примерно так:
class CLog
{
public:
........................................
// заходим в критическую секцию класса, добавляем сообешние в очередь сообщений, возвращаем // ссылку на лог для дальнейшей записи через <<
CLog& Message(LogLevel level);
// через этот оператор ведем запись любых типов данных. При необходимости можно указать // специализацию шаблона для конкретного типаtemplate <class T>
CLog& operator << (T message);
...........................................
};
template <>
CLog& CLog::operator << (endmsg manip)
{
// этот оператор отвечает за запись сообщения, удаление сообщения из очереди, выход из критической // секции. Таким образом, правильно обрабатываются "вложенные" сообщения.
}
Конечно, класс реализован как синглтон. Запись сообщения выглядит так:
Неудобство заключается в том, что после окончания каждого сообщения необходимо "засовывать" в лог объект класса endmsg (тоже самое можно изящнее реализовать через манипулятор). Но других путей обеспечения потокобезопасности я не нашел. Также достаточно громоздко выглядит "инициализация" сообщения. Можно сделать через макросы, но макросы не люблю. Почитав этот тред, узнал про трюк с enum'ом — красивое решение. Теперь осталось избавиться от endmsg().
В моём случае все было накручено на различных policy, т.е. многопоточная блокировка реализовывалась в MTPolicy так что я на чем-либо конкретном — не заморачивался.
ИНтересно было бы узнать насколько актуален mini-framework для логгирования ?
Имеет ли смысл мне потратить время на его доводку ?
И если да, то что бы All хотел там видеть ?
Шахтер молодец, srggal — тоже ничо
А по поводу навороченных логов (srggal, и др) есть уже готовые решения, зачем постоянно свой велосипед изобретать (например, log4cxx, etc).
srggal wrote: > ИНтересно было бы узнать насколько актуален mini-framework для > логгирования ? > Имеет ли смысл мне потратить время на его доводку ? > И если да, то что бы All хотел там видеть ?
В списке рассылки Boost'а был длинный тред о библиотеке логгирования: http://thread.gmane.org/gmane.comp.lib.boost.devel/134074
Здравствуйте, odisseyLM, Вы писали:
LM>Всем привет, Сори за флейм
LM>Шахтер молодец, srggal — тоже ничо LM>А по поводу навороченных логов (srggal, и др) есть уже готовые решения, зачем постоянно свой велосипед изобретать (например, log4cxx, etc).
+1
Именно наличие готовых решений и остановило меня от того о чём я спрашиваю здесь Re[4]: Я индус?
Здравствуйте, megawatt, Вы писали:
M>Как минимум загрузку сообщений из файла
Это Вы говорите о Локализации ?
Каких сообщений, из какого файла ?
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[2]: Я индус?
От:
Аноним
Дата:
16.02.06 16:19
Оценка:
Здравствуйте, Шахтер, Вы писали:
Ш>Здравствуйте, Chiрset, Вы писали:
C>>Несколько вопросов по поводу моей компетенции и читабельности кода который я пишу
C>>singleton<T>::instance() -- это вообще нормально? Т.е. это в порядке вещей что каждый вызов логгера сопровождаеться жутким синтаксическим оверхедом? К примеру, singleton<logger>::instance() << "Log" << endl;
Ш>Нет, не нормально. Нужно думать об удобстве собственной работы, краткости и выразительности кода. Логгер -- штука часто используемая, так что стоит сделать работу с ним удобной.
Ш>Например, с помощью глаголов.
Ш>
Ш>enum LogType { Log }; // Это приём я называю глаголом.
Ш>template <class T>
Ш>logger & operator << (LogType,const T &x) { return singleton<logger>::instance() << x ; }
Ш>...
Ш>Log << "Log message" << endl ;
Ш>
Ш>А по поводу индусов -- все индусы, просто в разной степени.
Что-то этого я не догнал. Если можно, объясните.
ЗЫ. Если это называется "индус", тогда я (который перед каждым объявлением ostringstream-а не ленится std:: приписывать), наверное, китаец...