паттерны, плюс .. что они измеряли? там мелкие словарики? где xpressive — он быстрее буст регексп ?
П.С. ну и т.к. гугль по слухам стейт машину работает, то и у них она объективно для определенных выражений, и для определенных даных будет работать быстрее.
что не всегда так. то данные не те, то выражения побольше.
Здравствуйте, reversecode, Вы писали:
R>результат R>самый худший для std::regexp
Не удивительно, об этом писали уже N лет назад. Они динамические, с выделением памяти, нельзя создавать в цикле и т.д. и т.п. Ждём, когда комитет примет constexpr regex
Здравствуйте, reversecode, Вы писали:
R>самый худший для std::regexp
Мало того, он любит падать при парсинге текста со stack overflow. И вообще, непонятно почему не сделают нормальную реализацию, т.к. то, что получилась какашка уже давно известно.
PS: boost::regex очень близок к нему по API и быстрее в моём случае примерно в 10-20 раз. Так что юзаю именно его.
Здравствуйте, reversecode, Вы писали:
R>результат
R>самый худший для std::regexp R>...
Не мудрено. Сам на это наступил. В одной библиотеке, форматный вывод, в котором использовался std::regexp, вдруг, стал бутылочным горлышком. Полез смотреть внутрь, а там... new на new и new погоняет, причем не во время "компиляции" регулярного выражения, а прямо во время match. Тут я офигел и понял, что стандартные регулярки нельзя использовать ни в коем случае, коме как при поиске паттерна в тексте 4ГБ и больше.
Вообще интересно, какие требования стандарта привели к такому безобразию. Как обычно представляешь себе работу regexp: сначала можем немного потерять времени при компиляции регулярки в супер-пупер оптимизированные и быстрый ДKA/HKA, а потом очень быстро используешь, типа скорость — одно сравнение на символ по таблице или около того, но не тут-то было
