Форум
Философия программирования
Тема
Как правильно задавать вопросы
B
I
abc
U
X
3
X
3
H1
H2
H3
H4
H5
H6
Asm
C/C++
C#
Erlang
Haskell
IDL
Java
Lisp
MSIL
Nemerle
ObjC
OCaml
Pascal
Perl
PHP
Prolog
Python
Ruby
Rust
SQL
VB
Здравствуйте, vdimas, Вы писали: V>Здравствуйте, VladD2, Вы писали: VD>>В нем не эффективные алогоритмы. V>Там нет никаких алгоритмов. Вообще. Просто способ декларативной комбинации функторов. VD>>Как только горамматика выходит за LL(1) производительность парсера резко падает. Вплоть до экспоненты. V>Дык, на то они и комбинаторные парсеры, что УГ полное. И они должны заметно сливать даже на LL(1) в сравнении с табличной реализацией. Чем "шире" набор правил на каждом уровне, тем в большее число раз должны сливать. Потому что комбинаторные парсеры - это тупой рекурсивный спуск с перебором. VD>>Но в любом случае его скорость в простых случаях обусловлена (в немалой мере) тем, что он использует генерацию кода по модели. V>Не только из-за генерации кода. А еще из-за выделение регулярного подмножества, на котором у вас идет не тупой нисходящий ПЕГ-перебор, а восходящий детерминированный разбор автоматом. VD>>Подход Немерла и N2 позволяет куда больше чем С++-ное метапрограммирование на шаблонах (использованное в бусте). Потому позволяет добиться лучшей скорости. V>ХЗ. Сколько раз не меряли - табличные лексеры и парсеры работают фактически с той же скоростью, что построенные на if/switch/case. При том, что последние требуют кодогенерации ("Подход Немерла" (С)), а первые - нет.
Теги:
Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например:
"Visual Studio" .NET
Имя, пароль:
Загрузить
Нравится наш сайт?
Помогите его развитию!
Отключить смайлики
Получать ответы по e-mail
Проверить правописание
Параметры проверки …