Здравствуйте, Tonal-, Вы писали:
T>Наверное надо включить #include <vector> если есть элементы зависимые от std::vector.
Это я недоглядел.
Данныай файл включен в более развесистую либу, где с вектором разбираются вполне отдельно.
Впрочем, включение <vector> и не надо — достаточно forward-declaration.
T>Не совсем понятно назначение функций get_match_at и set_match_count. Почму нельзя просто воспользоваться методами operator[]() и resize().
Эти функци реализуют дополнительный контейнеро-независимый уровень абстракции.
Читай ниже — поймешь.
T>а во вторых разные компиляторы их по разному трактуют (Borland например требует полной спецификации шаблонных параметров.)
Есть только одна трактовка — стандарт C++. Если компилятор стандарт не понимает, то идет он пусть в /dev/nul
T>По моему operator[]() для match_vector и для match_array несколько расходятся. Если уж проверять выход за граници, то для обоих, или уж не проверять совсем.
Гм. А где я проверяю границы? Это отадно на откуп реализации контейнера.
T>Начитался давеча Саттера — он говорит что не следует применять наследование без вестких на то причин — это я о match_vector. T>Собственно если переименовать функцию reset() в clear() то вместо match_vector можно будет использовать и std::vector, и std::deque и boost::array. T>В общем непонятна суть ограничений.
Суть в том, что требуется обьект способный принимать и хранить подсовпадения.
Для этого был сделан match_array который описывает в описывает минимальные требования к
контейнеру подсовпадений. И уже потом, был добавлен match_vector который аналогичен match_array.
В общем, я согласен с твоим замечанием, что match_vector слишком исскуственно ограничен и можно хранить подсовпадения в любом контейнере который удовлетворяет требованиям "Sequence".
Но это ты как-нибудь сам реализуй
Работы, сосно гря немного:
— переименовать reset() в clear()
— переименовать match_type в value_type
— реализовать get_match_at и set_match_count для контейнеров других типов.
T>Есть некоторый недостаток в ID к mark-у: непонятно как избежать совподения.
В смысле, как избежать совпадения ID у двух разных mark-ов ?
А никак — да и ненужно — раз усер дал разным mark-ам одинаковый ID, то этого он и хотел
T>По моему было бы очень удобно, если для любого вырожения можно было бы получить максимальное количество подсовпадений. Реализация — тривиальна: для символьных классов = 0, для mark = подвырожение + 1, для контейнеров = сумма подвырожений.
Не вижу смысла. Количество подвыражений — функция входной строки, а не регулярного выражения. Вина этому — операторы-повторители.
Например, выражение "(a)*" на строке "aaaaaaaaaaa" даст очень много подвыражений, а на строке "bbbbbb" ни одного
T>Может быть следует предоставить 2 формы alt — полный перебор (POSIX-like),
Этот вариант реализован.
T>или до первого совпадения (Perl-like) — некоторые выражения можно соптимизировать.
Опять-таки: не вижу смысла. Оптимизация такого рода — задача усера. Например, если он напишет
выражение "(.*this|.*that|.*there)" — ежу понятно насколько быстрым будет такое варажение и как его оптимизировать
T>Ну вроде на первый взгляд всё, спать пора. ;-в
Нухшо, словечко "вырожение" от которого меня просто трясет и хочется кого-нибудь спишем на то что тебе спать очень хочется
Здравствуйте, Дарней, Вы писали:
Д>интересно, кто-нибудь знает, как работают POSIX NFA движки? Используют двухстековый метод?
Смотрел gnu regex, там вообще "классические" автоматы не используются.
Генерируется какой-то псевдокод, который потом интерпретируется.
Что-то подобное происходит и в boost::regex, но я там глубоко не копался.
Дело в том, что посредством автоматов некоторые вещи (маркирование подвыражений, обратные ссылки) сделать достаточно трудно, если не невозможно. По крайней мере, мне не удалось на автомате реализовать обратные ссылки.
Д>А как там решается проблема с "ленивыми" квантификаторами?
Для недетерминированного автомата — это вообще не проблема. Он может быть "уступчивым", а может быть "жадным" в зависимости от того, что предпринимать, если в текущем наборе альтернатив есть финальное состояние.
Есть такие варианты:
(1) останавливаемся, несмотря на то, что есть "не финальные" альтернативы. Получим наикратчайшее совпадение — автомат будет "уступчивым"
(2) продложаем, пока финальное состояние не будет единственным в наборе альтернатив. Получим наидлиннейшее совпадение — автомат будет "жадным"
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>Дело в том, что посредством автоматов некоторые вещи (маркирование подвыражений, обратные ссылки) сделать достаточно трудно, если не невозможно. По крайней мере, мне не удалось на автомате реализовать обратные ссылки.
верно, некоторые вещи сделать нельзя. еще есть проблемы с метасимволами, насколько я понимаю
но можно попробовать прикрутить дополнительные фичи поверх автомата
DEA>Есть такие варианты: DEA>(1) останавливаемся, несмотря на то, что есть "не финальные" альтернативы. Получим наикратчайшее совпадение — автомат будет "уступчивым" DEA>(2) продложаем, пока финальное состояние не будет единственным в наборе альтернатив. Получим наидлиннейшее совпадение — автомат будет "жадным"
а если внутри выражения есть несколько квантификаторов для разных его частей, из них один "жадный" а другой "ленивый"?
Здравствуйте, Дарней, Вы писали:
DEA>>Дело в том, что посредством автоматов некоторые вещи (маркирование подвыражений, обратные ссылки) сделать достаточно трудно, если не невозможно. По крайней мере, мне не удалось на автомате реализовать обратные ссылки.
Д>верно, некоторые вещи сделать нельзя. еще есть проблемы с метасимволами, насколько я понимаю
C метасимволами как раз проблемы нету. Конечно, если автомат NFA. Просто трактуешь этот метасимвол как "простой" символ — и при двустековом моделировании он отработает нормально. А вот для DFA — метасимволы — это пипец полный — в особенности если алфавит — юникодный — автомат разрастается до поистине ненормальных размеров.
Д>но можно попробовать прикрутить дополнительные фичи поверх автомата
...Тогда проще рекурсивно-нисходящим методом...
DEA>>Есть такие варианты: DEA>>(1) останавливаемся, несмотря на то, что есть "не финальные" альтернативы. Получим наикратчайшее совпадение — автомат будет "уступчивым" DEA>>(2) продложаем, пока финальное состояние не будет единственным в наборе альтернатив. Получим наидлиннейшее совпадение — автомат будет "жадным"
Д>а если внутри выражения есть несколько квантификаторов для разных его частей, из них один "жадный" а другой "ленивый"?
То же самое. Метишь состояния соответствующие окончанию подвыражения как "полуфинальные" и при моделировании "уступчивых" подвыражений предпочитаешь полуфинальное состояние всем остальным состояниям.
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>C метасимволами как раз проблемы нету. Конечно, если автомат NFA. Просто трактуешь этот метасимвол как "простой" символ — и при двустековом моделировании он отработает нормально. А вот для DFA — метасимволы — это пипец полный — в особенности если алфавит — юникодный — автомат разрастается до поистине ненормальных размеров.
не совсем понял. вставлять их во входной поток, наравне с обычными символами?
спишем на то что тебе спать очень хочется 
