Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Статический анализ кода... Исполнение не требуется.
я думал и над другим вариантом - синтаксический разбор текста. так скажем парсинг MQL и создание структуры программы.
но к её реализации даже не знаю с чего подступится. практики не было.
Почему-бы и нет, если хочется.
Неужели неочевидна нерешаемость этой задачи? Эдак можно было бы упразнить пары арифметических () [] и операторных {} скобок, и заменить на единственную - открывающую. Слабо?
;)
Почему же.
Ведь не мало и унарных операций.
Выбор неправильного средства реализации говорит о непрофессионализме.
да какая разница на чем программить. В любом деле важна матмодель решения.
Все остальное не имеет
Статический анализ кода... Исполнение не требуется.
Код бьётся на функции (блоки) - дальше анализируется кто кого вызывает.
У меня тоже такая мысль бродит. Только всю программу придётся досконально парсить, дабы отделить горы от прыщей...
Да и топикстартеру похоже не это нужно, ежли я правильно проинтуичил ему надо чтоб распечатывались вызовы по факту. Ну типа если условия вызова состоялись.
я думал и над другим вариантом - синтаксический разбор текста. так скажем парсинг MQL и создание структуры программы.
но к её реализации даже не знаю с чего подступится. практики не было.
Что есть функция?
.
[ словечко пробел / этого может и не быть ] словечко имя функции скобочка "(", что-то там, скобочка закрывающая ")"
фигурная открывающая {
.
какой-то код
фигурные скобки считаем парами {, }
.
фигурная закрывающая }
.
Первая часть работы сделана.
:))
задача (если читали первый пост) сводится к добавлению всего одной служебной-функции в каждую функцию исходного кода - сразу после "{".
Но с таким расчетом, чтоб получить все проходы исходного кода и построить дерево вызовов.
При этом никоим образом не меняется ни входные параметры исходных функций, ни их результаты или код внутри
Не про чистый трейс идет речь. А только про построение графа функций.
Вот фрагмент журнала:
Почему же.
Ведь не мало и унарных операций.
Ну так данная операция явно не унарна. "Состояние вложенности" при статическом анализе текста - унарно. При динамической трассировке - бинарно. Есть ВХОД и есть ВЫХОД.
Не?
У меня тоже такая мысль бродит. Только всю программу придётся досконально парсить, дабы отделить горы от прыщей...
Да и топикстартеру похоже не это нужно, ежли я правильно проинтуичил ему надо чтоб распечатывались вызовы по факту. Ну типа если условия вызова состоялись.
При парсинге - вызовы по факту сами обнаружатся. Кто с кем и откуда...
поэтому пока что это единственное завершенная идея решения.
.
Кстати... добавлю:
.
- изначально текст программы анализируется "лексером".
Лексер бьет текст программы на "токены".
В нашем случае токенами являются:
.
- whitespace - пробелы, табуляции, концы строк и т.д. -
раз пишем не форматтер, просто игнорируем этот stuff
- скобки ( / )
- скобки [ / ]
- скобки { / }
- операторы + - / *
- служебные символы ;,
всё остальное по сути является идентификаторами
(числа тоже войдут в эту группу- но нам все равно).
.
При парсинге лексинге заполняются структурки типа
struct { типТокена, строкаТокена }
.
Для парсинга я использовал вложение типа
struct Tocken { типТокена, строкаТокена, list<Token> список вложенных токенов }
но здесь можно подумать как проще.
.
А дальше выполнить группировку о которой я говорил выше- тривиально.
.
Собственно, сочетание лексер + парсер- это классика жанра.
По поводу lex/flex/bison/ant-lr не проконсультирую (я даже названий таких не знаю ;-D)-
я писал именно hand-made.
ок. спасибо всем за диспут.