"иерархические логи" и автоматическя обработка исходников. (есть или стоит делать?)

[Denjs]

гм.. подскажите если это уже сделано. или дайте совет "как начать делать" - киньте каким синтаксическим анализатором или обработчиком кода...?

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

Что то в данном направлении уже далал, и оно вроде успешно было и весьма полезно - особенно если в программе куча рекурсивных процедур,
большой объем обрабатываемых данных и надо отслеживать "как мы сюда вообще попали и из-за каких значений переменных возникло исключение"...
Удобно смотреть, и понимать где управление возвращается в исходную функцию, и "насколько глубоко" программа зарылась внутрь... ну и т.п.
и вообще волшебно когда клиент "присылает с багрепортом такой лог с дампами промежуточных данных..."
(превед "1С-совской конвертации данных" ... ("мать-мать-мать".. кто пробовал отлаживать ошибки в этих обработках - тот поймет весь возникающий с этим гемор...) ... среда другая, но суть та-же...)

Собственно, делать такую переработку кода руками - геморно - по идее надо перед каждым(!) выходом из процедуры, и после каждого входа в процедуру вставлять руками вызовы которые будут открывать/закрывать ветку лога.

Собсвенно возникает вопрос об автоматической переработке исходников.
Вопрос кем, и чем? что есть в данном направлении "уже сделанного" или что можно-было-бы брать за исходную отправную точку?

(будет выходной лог в виде вложенных таблиц HTML, или будут это ветки XML или ещё что - не суть важно... это вопрос технической реализации...)

[KiWi]

gdb или любой другой дебагер.

[Denjs]

gdb или любой другой дебагер.

простите, но видимо вы не набивали тех шишек о которых я рассказал.

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

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

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

[Goodvin]

Показал ветку знакомому программисту с большим опытом.
Он сказал дословно следующее:
"Надо не логи в дерево строить, а научиться правильно проектировать ПО.
Программе, дефективной by design, не помогут ни деревья логов, ни дебаггеры.
Дайте автору этой идеи книгу по алгоритмизации."

[serzh-z]

Надо не логи в дерево строить, а научиться правильно проектировать ПО.

Совет, увы, в стиле "Знаю, но не скажу, потому что... сам, на самом деле не знаю...". На вопрос "кто виноват" он, может быть, и отвечает, на вопрос "что сейчас делать" - ни в коем разе.

Собсвенно возникает вопрос об автоматической переработке исходников.

Думается, что нужно дружить с разработчиками языка, для которого требуется сделать подобный автоматический рефакторинг, или просто очень хорошо знать спецификацию языка и уметь пользоваться yacc/Bison и lex/flex...

[Goodvin]

Надо не логи в дерево строить, а научиться правильно проектировать ПО.

Совет, увы, в стиле "Знаю, но не скажу, потому что... сам, на самом деле не знаю...". На вопрос "кто виноват" он, может быть, и отвечает, на вопрос "что сейчас делать" - ни в коем разе.

Думаю, что знает.
Человек порядка 10 лет пишет серьезное ПО для управления технологическими процессами на производстве.
Ну, спорить не стану, почему он не выдал рецепта с подробным развёрнутым ответом на вопрос "Что делать" - не знаю.

[Denjs]

Думаю, что знает.
Человек порядка 10 лет пишет серьезное ПО для управления технологическими процессами на производстве.
Ну, спорить не стану, почему он не выдал рецепта с подробным развёрнутым ответом на вопрос "Что делать" - не знаю.

Ваш советчик конечно прав... но !
в сложно-в*****нутой системе автором которой не обязательно являюсь я исправить что-либо весьма проблемно.
конкретный пример - правда из 1С - "технолоия конвертации данных". как первая так и вторая.
принцип заложенный при выгрузке данных - рекурсия, в стиле выгрузить_документ() - это последовательный вызов выгрузить_реквизит() для каждого из реквизитов - а реквизит при этом может быть ещё и документом и "наша песня хороша - начинай с начала" - выгрузить_документ() и дт......
- сложно сказать плохо это или хорошо "спроектированно"... думаю я бы маловероятно что лучше сделал...

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

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

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

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

PS: технологические процессы на производстве - конечно сложны, но в "системном плане", имхо; но как минимум одна область обладает гораздо большим геморроем: "оборот документов" - это вещь куда более замороченная и "зачастую с неясной человеческой (и нечеловеческой) логикой", которую практически никогда не удается "спроектировать нормально". тому кто алгоритмизирует так что бы "не было геморроя" "ни сейчас ни при дальнейшем развитии" вещи такого плана - можно памятник поставить. и нобелевскую присудить.
PPS: .... и наверное придется ещё и не пускать к такой системе людей - что бы она не сломалась.. <_<

Думается, что нужно дружить с разработчиками языка, для которого требуется сделать подобный автоматический рефакторинг, или просто очень хорошо знать спецификацию языка и уметь пользоваться yacc/Bison и lex/flex...

язык-то C++, с QT-шными "приблудами"...
ладно... посмотрю что за инструменты вы перечислили, немного "порою вокруг" и попробую потихоньку писать свой "парсер исходника с/с++"...
когда-то меня хватило на обсфукатор 1С-ного кода.. думаю есть шансы подружиться и с с++....

[v04bvs]

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


А вообще идея примерно такая:

Код: Выделить всё

 class FunctionLogger {
 public:
     FunctionLogger(const char *function) : function(function) { log_enter(function); }
     ~FunctionLogger() { log_exit(function); }
 private:
     const char *function;
 };


 #define LOG_FUNC FunctionLogger functionLogger_(__func__)

 void myFunc() {
    LOG_FUNC;
    ...
 }

Там же можно вставить файл, номер строки и т.д. Я даже как то так делал:

Код: Выделить всё

void myFunc(int x, int y, MyClassWithOverloadedOutputOperator o) {
    LOG_FUNC(x, y, o);

и он писал в логах примерно так:

Код: Выделить всё

myFunc(x = 2, y = 3, o = {1,2,3}) { // myfunc.cpp:143
...
} // myFunc

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

А самое главное — можно сделать хороший переносимый стектрейс в любой момент программы.

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

[Portnov]

У С++ довольно сложный синтаксис. Думаю, проще всего будет взять парсер от g++.

[Denjs]

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

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

v04bvs:правда пришлось повозиться немножко.

... ыгы... лень ещё раз повторять это... ^_^ ) от того весь флуд и идет )

[AEK]

Человек порядка 10 лет пишет серьезное ПО для управления технологическими процессами на производстве.

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

[v04bvs]

v04bvs:правда пришлось повозиться немножко.

... ыгы... лень ещё раз повторять это... ^_^ ) от того весь флуд и идет )

Если честно, не советую препроцессить C++. Увязнете. Это такое болото. Чтобы AST построить, нужно чуть ли не полкомпилятора написать. Никакого bison/yacc Хотя, конечно, дело ваше. Если задумаете писать, то, видимо, gcc придётся модифицировать (а это ещё одно болото ), не забывайте что он GPL и старайтесь не получить vendor lock-in (т.е. ситуацию, когда ваши исходники только gcc сможет скомпилировать).

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

PS была бы у вас Java Кстати, то, что вы хотите сделать, называется модным словом "Аспектно-ориентированное программирование" (Aspect-oriented programming). Попробуйте погуглить в сочетании с C++, вдруг найдёте что-нибудь.

[d_n_k]

Код: Выделить всё

#define LOG bla-bla-bla
#define { { LOG ("Begin ");
#define } LOG("end"); }

begin и end замени на нужные макросы типа __FUNCTION__ __LINE__
пересобрал, получил тормозное приложение, тк логи пишутся на каждый чих

[serzh-z]

тк логи пишутся на каждый чих

Если бы это даже было возможно в языке, то получилось бы примерно следующее: в каком-то блоке (if, while и т.д. с "{") логирование включено, в каком-то (одностроных if) нет...

[Denjs]

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

ну... идея конечно ... )
подменить фигурные скобки... но думаю не на каждом компилторе прокатит...

но как "подход-в-лоб" и "в первом приближении" - как минимум забавно ) запомню.

[Goodvin]

Человек порядка 10 лет пишет серьезное ПО для управления технологическими процессами на производстве.

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

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

Denjs:
теперь стала чуть более понятна Ваша задача.
Закину удочки знакомым "зубрам" из торгово-учетной сферы, может чего дельного и подскажут.