Regex: boost:: xpressive vs boost:: regex

Я хотел бы сделать некоторые регулярные выражения на С++, поэтому я посмотрел на interwebz (да, я начинающий/средний с С++) и нашел этот ответ SO.

Я действительно не знаю, что выбрать между boost:: regex и boost:: xpressive. Каковы плюсы и минусы?

Я также читал, что boost:: xpressive, противоположное boost:: regex, является библиотекой только для заголовков. Трудно статически компилировать boost:: regex в Linux и Windows (я почти всегда пишу кросс-платформенные приложения)?

Я также заинтересован в сравнении времени компиляции. У меня есть текущая реализация с использованием boost:: xpressive, и я не слишком доволен временем компиляции (но у меня нет сравнений с boost:: regex).

Конечно, я открыт для других предложений для реализаций регулярных выражений. Требования бесплатны (как в пиве) и совместимы с http://nclabs.org/license.php.

Ответ 1

Хорошо, если вам нужно создать регулярное выражение во время выполнения (т.е. позволить пользователю вводить регулярное выражение для поиска), вы не можете использовать xpressive, поскольку это только время компиляции.

С другой стороны, поскольку это конструкция времени компиляции, это должно принести больше пользы от вашего оптимизатора, чем regex.

Я делаю достаточно вещей с Boost.MPL, StateChart и Spirit, что 220 Кбайт предупреждений и ошибок компилятора не сильно меня беспокоит. Если вам это нравится, придерживайтесь Boost.Regex.

Если вы используете xpressive, я настоятельно рекомендую включить -Wfatal-errors, так как это прекратит компиляцию (и дальнейшие ошибки) после первой строки "error:".

Для времени компиляции это не соревнование. Boost.Regex будет быстрее *. Тот факт, что xpressive использует MPL, приведет к значительному увеличению времени компиляции.

* Предполагается, что вы только создаете dll/so once

Ответ 2

Одно довольно важное различие заключается в том, что Boost Regex может поддерживать привязку к ICU для поддержки Unicode (классы символов и т.д.) Boost Regex ICU Support.

Насколько я могу судить, Boost Xpressive не поддерживает такую поддержку.

Ответ 3

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

Ответ 4

Предполагая, что вы используете достаточно недавний компилятор, есть довольно хороший шанс, что он уже содержит пакет регулярных выражений. Попробуйте просто выполнить #include <regex> и посмотреть, находит ли компилятор его.

Единственный трюк в том, что он может быть в обоих (или обоих) двух разных пространствах имен. Регулярные выражения были включены в TR1 стандарта С++, а также в (окончательные проекты) С++ 11. Версия TR1 находится в пространстве имен с именем tr1, где стандартная версия находится в std, как и остальная часть библиотеки.

FWIW, это по существу то же самое, что и Boost regex, а не Boost Xpressive.

Ответ 5

Я бы попытался дополнить ответы других людей, углубившись в тему регулярных выражений времени компиляции (CTR) и динамических регулярных выражений (RTR) более теоретически (этот вопрос подразумевается в вопросе OP косвенно ИМХО). Регулярное регулярное выражение является более известным и популярным (большинство языковых реализаций основных библиотек), я полагаю, из-за исторических причин. Они в порядке, когда регулярное выражение определяется во время выполнения, в отличие от CTR. Оба работают на основе конечных автоматов.

RTR "компилируются" и интерпретируются каким-то универсальным конечным автоматом (универсальный означает его тип интерпретатора, схема которого дана во время выполнения, "скомпилирована" в некоторой внутренней структуре данных - когда вы передаете строку регулярного выражения, тогда интерпретируется во время выполнения).

Но CTR "компилируется" во время компиляции и специфичен для конкретного регулярного выражения, поэтому вы не можете их использовать, когда regex предоставляется во время выполнения (приложения, такие как текстовые редакторы, файловые/интернет-поисковые системы).

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

Что касается конкретных реализаций - существует много RTR, но не так много CTR. Для С++ они выше упомянутых версий Boost и STL С++ 0x11. Они могут потребоваться для оптимизации производительности/размера регулярного выражения сгенерированного использования кода/памяти, в основном для встроенных систем или приложений с высокой производительностью. Вопрос о CTR Поиск CTR-реализаций сложнее, один пример, если он найден, - это проект генератора кода Re2C, реализация Java CTR и реализация С#, показывающая компиляцию во время выполнения (в IL, а не внутренняя структура данных) Regex [есть вопрос SO о нем]

P.S. Извините, не удалось опубликовать некоторые релевантные ссылки из-за репутации