Здравствуйте, Nikeware, Вы писали:
N>У меня когда-то стоял выбор — rich или Crystal. ИХМО Я выбираю первый. Аргумент — скорость работы. N>А почему ExtTextOut — головняк? Редактор достаточно толково построен. Все сводится к ParseLine. И "представление" отделено от самого процесса редактирования. CrystalBuffer занимается редактированием. А CrystalView при рисовке строк запрашивает как их рисовать. Можно усомнится в скорости парсинга. Ведь на первый взгляд кажется, что отрисовка достаточно частая операция и постоянно тратить время на разбор слишком расточительно. Но это если текст разбирать "руками" — массивы ключевых слов, поиск в них, сравнение в выделеным токеном и.т.д. Проходил я это. Потом когда сделал на основе автоматных грамматик (регулярных выражений- кому как нравится). Все стало летать. Причем при росте сложности и объема ключевых слов и лексических конструкций скорость совершенно не падает. Я те парсеры, что идут вместе с CrystalEdit — это не более чем примеры. В реальности делается это по другому. Потому как у многих такие конструкции как #define выглядят совершенно по разному:
CrystalEdit я не хочу, чтобы не связываться с MFC. Вопрос стоял — делать раскраску РУКАМИ с помощью ExTextOut или rich edit. Вроде с rich edit все оказывается совсем не сложно, даже область для меток слева где устанавливаются брейкпойнты и т.д. легко создать с помощью EM_SETMARGINS. Мой вопрос про "как определить на какие строки влияют операции..." снимается.
А насчет лексического/синтаксического анализа текста — так их я уже сделал руками, благо разбираемая грамматика совсем простая:
Текст состоит из строк, каждая строка независима.
Строка -> :Пауза | Текст_на_отправку_устройству | Пустая_строка
Пауза -> Целое_число_десятые_доли_секунды
Текст_на_отправку_устройству -> Команда | Команда Операнд | Непонятно_что_наверно_неизвестная_команда
Команда, Операнд, Непонятно_что -> любой текст пока не встретим ';' и '\n'
+ однострочные комментарии ';'
Нужно подсвечивать распознанные команды просто для удобства, т.к. их порядка 100 и могут быть добавлены новые. А так строка отправляется на исполнение целиком как есть и нам по барабану где там команда, а где операнд.
N>
N>#define
N>
N>
N># define
N>
N> — А ведь должен в обеих ситуациях покрасить в синий
N>Как ни крути, а "руками" все ситуации не покроешь. Руки устанут, да и голова заболит N>Юзать надо однозначно автоматные грамматики. Вначале все это конечно "завести" надо. С этим естественно попарится придется. Но окупится с лихвой. Поверьте.
Ну кто же спорит, естественно нужно юзать автоматные грамматики (блин тоже не знаю как их правильно называть). Другое дело что в моем случае мало смысла привлекать генераторы анализаторов типа yacc/lexx если вы об этом.
Здравствуйте, ukman, Вы писали:
U> Потом когда сделал на основе автоматных грамматик (регулярных выражений- кому как нравится). Все стало летать. Причем при росте сложности и объема ключевых слов и лексических конструкций скорость совершенно не падает.
U>А можно узнать, как автоматы строились? Ну не руками же вы писали? Наверное lex или что-то подобное?
Практики у меня в этом деле мало, в основном теория.
Вроде почти везде используется т.н. синтаксически управляемая трансляция. Это значит что первой фазой трансляции управляет конечный автомат — синтаксический анализатор, для сложных грамматик он может быть создан генератором анализаторов, рулит здесь YACC. Этот анализатор не имеет дело с сырым текстом, а запрашивает токены по одному у лексического анализатора.
Лексический анализатор (тоже КА) по запросу читает посимвольно текст пока не распознает допустимую лексему и возвращает токен (т.е. тип лексемы, например число, оператор, идентификатор) и его атрибуты (значение числа или текст идентификатора). Всякие пробелы/комментарии отбрасываются. Лекс. ан. тоже может быть создан генератором анализаторов, под YACC вроде удобнее использовать LEXX.
На входе генераторов анализаторов — регулярные выражения описывающие грамматику/лексику и описание действий, соответствующих некоторой распознаной конструкции, на выходе — С код анализатора.
Для YACC наверно можно найти готовое описание многих языков, насчет C++ не уверен, а просто C вроде есть. Но где не знаю
Если надо только раскрасить, то на фазе синтаксического анализа все и заканчивается.
Хоть че то полезное я сказал ??
Перечитал свой постинг и понял что меня не туда понесло.
Чтобы раскрашивать как в IDE VC нужно просто различать:
1. ключевые слова языка и директивы препроцессора
2. комментарии
3. все остальное
Поскольку ключевые слова зарезервированы и их ни с чем не спутаешь, то можно обойтись только лексическим анализом, а синтаксис языка совершенно не интересует.
Д>А насчет лексического/синтаксического анализа текста — так их я уже сделал руками, благо разбираемая грамматика совсем простая: Д>Нужно подсвечивать распознанные команды просто для удобства, т.к. их порядка 100 и могут быть добавлены новые. А так строка отправляется на исполнение целиком как есть и нам по барабану где там команда, а где операнд.
Д>Ну кто же спорит, естественно нужно юзать автоматные грамматики (блин тоже не знаю как их правильно называть). Другое дело что в моем случае мало смысла привлекать генераторы анализаторов типа yacc/lexx если вы об этом.
Ну да, в данной ситуации мудрить с yacc/lexx не стоит. Это именно тот случай когда "руками" можно .
Просто у меня лично стояла задача более общая — С++, Perl, JScript, C#. И в дальнейшем еще много чего придется реализовывать. Поэтому когда я "руками" сделал пару первых парсеров, понял, что так дело дальше не пойдет. В ошибках "вязнешь"- что в болоте. Пришлось искать более общее решение. Потратил время, но теперь оно окупается.
При достаточном опыте у меня на очередной язык уходит не больше одного рабочего дня (чтобы изучить саму структуру языка и написать лексический анализатор).
Здравствуйте, Диагностик, Вы писали:
Д>Перечитал свой постинг и понял что меня не туда понесло. Д>Поскольку ключевые слова зарезервированы и их ни с чем не спутаешь, то можно обойтись только лексическим анализом, а синтаксис языка совершенно не интересует.
Да. Лексического анализатора хватает на 95% случаев.
Здравствуйте, Nikeware, Вы писали:
N>При достаточном опыте у меня на очередной язык уходит не больше одного рабочего дня (чтобы изучить саму структуру языка и написать лексический анализатор).
Эх, только это хорошо для себя, а как другой пользователь захочет пользоваться твоим редактором, и еще захочет какой нибудь новый язык в анализатор добавить. IMHO, лучше всего когда это описываеться в каких-то конфигурационных файлах, на каком нибудь языке, что нибудь ввиде регулярных выражений (как например LEX файлы) проанализировав который можно легко получить КА (думаю КА для подсветки синтаксиса хватит).
Здравствуйте, comer, Вы писали:
C>Здравствуйте, Nikeware, Вы писали:
N>>При достаточном опыте у меня на очередной язык уходит не больше одного рабочего дня (чтобы изучить саму структуру языка и написать лексический анализатор). C>Эх, только это хорошо для себя, а как другой пользователь захочет пользоваться твоим редактором, и еще захочет какой нибудь новый язык в анализатор добавить. IMHO, лучше всего когда это описываеться в каких-то конфигурационных файлах, на каком нибудь языке, что нибудь ввиде регулярных выражений (как например LEX файлы) проанализировав который можно легко получить КА (думаю КА для подсветки синтаксиса хватит).
Так вы батенька чужие мысли на расстоянии читать умеете! Нехорошо
Естественно. Это следующий логический шаг в подобной ситуации.
Здравствуйте, Nikeware, Вы писали:
N>Просто у меня лично стояла задача более общая — С++, Perl, JScript, C#.
В C# для тебя есть замечательные грабли
Там вроде ключевые слова не зарезервированы и для ДЕЙСТВИТЕЛЬНО правильной раскраски надо решать что есть else в данном контексте — ключевое слово или переменная.
Спорю на что угодно что ты игнорировал это извращение
Интересно, как родное IDE раскрасит переменную else?
Здравствуйте, Диагностик, Вы писали:
Д>Здравствуйте, Nikeware, Вы писали:
N>>Просто у меня лично стояла задача более общая — С++, Perl, JScript, C#.
Д>В C# для тебя есть замечательные грабли Д>Там вроде ключевые слова не зарезервированы и для ДЕЙСТВИТЕЛЬНО правильной раскраски надо решать что есть else в данном контексте — ключевое слово или переменная. Д>Спорю на что угодно что ты игнорировал это извращение Д>Интересно, как родное IDE раскрасит переменную else?
Цитирую MSDN:
Keywords are predefined reserved identifiers that have special meanings to the compiler. They cannot be used as identifiers in your program unless they include @ as a prefix. For example, @if is a legal identifier but if is not because it is a keyword.
Ниже идет таблица с ключевыми словами (не привожу из-за размеров), но там else есно есть .
Вся фишка в @. А это я отрабатываю
N>Keywords are predefined reserved identifiers that have special meanings to the compiler. They cannot be used as identifiers in your program unless they include @ as a prefix. For example, @if is a legal identifier but if is not because it is a keyword.
Значит я не прав. Мне казалось что @ используется только при объявлении, а в дальнейшем — без нее.
— А ведь должен в обеих ситуациях покрасить в синий 
