regex: boost :: xpressive vs boost :: regex

Question

Quería hacer algunas expresiones regulares en C++, así que busqué en el interwebz (sí, soy un principiante/intermedio con C++) y encontré this SO answer.

Realmente no sé qué elegir entre boost :: regex y boost :: xpressive. ¿Cuáles son los pros/contras?

También leí que boost :: xpressive opuesto a boost :: regex es una biblioteca de solo encabezado. ¿Es difícil compilar boost :: regex estáticamente en Linux y Windows (casi siempre escribo aplicaciones multiplataforma)?

También me interesan las comparaciones del tiempo de compilación. Tengo una implementación actual usando boost :: xpressive y no estoy muy contento con los tiempos de compilación (pero no tengo comparaciones para impulsar :: regex).

Por supuesto estoy abierto para otras sugerencias para implementaciones de expresiones regulares también. Los requisitos son gratuitos (como en la cerveza) y compatibles con http://nclabs.org/license.php.

Answer 1

Bueno, si necesita crear una expresión regular en tiempo de ejecución (es decir, dejar que el usuario escriba una expresión regular para buscar) no puede usar xpressive ya que es solo tiempo de compilación.

Por otro lado, dado que es una construcción en tiempo de compilación, debería beneficiarse más de su optimizador que el regex.

Hago bastantes cosas con Boost.MPL, StateChart, y Spirit que 220 KB de advertencia de compilador y errores realmente no me molestan demasiado. Si eso te suena mal, quédate con Boost.Regex.

Si usa xpressive, recomiendo activar -Wfatal-errors ya que esto detendrá la compilación (y otros errores) después de la primera línea 'error'.

Para el tiempo de compilación, no hay problema. Boost.Regex será más rápido *. El hecho de que xpressive use MPL hará que los tiempos de compilación aumenten drásticamente.

* Esto supone que sólo se genere la DLL/lo que una vez

Answer 2

Cuando uso las bibliotecas de Boost tiendo a inclinarme hacia el uso de librerías solo de encabezado, debido a problemas de compatibilidad de plataforma cruzada. La desventaja de esto es que cuando el compilador informa un error relacionado con el uso de la biblioteca, el resultado del encabezado solo tiende hacia el arcano.

Answer 3

Suponiendo que está utilizando un compilador razonablemente reciente, hay una probabilidad bastante buena de que ya incluya un paquete regex. Intenta simplemente hacer #include <regex> y ver si el compilador lo encuentra.

El único truco para las cosas es que podría estar en cualquiera (o ambos) de dos espacios de nombres diferentes. Regexes se incluyeron en TR1 del estándar de C++, y también están en (los borradores finales de) C++ 11. La versión TR1 está en un espacio de nombre llamado tr1, donde la versión estándar está en std, al igual que el resto de la biblioteca.

FWIW, esto es esencialmente lo mismo que Boost regex, no Boost Xpressive.

Answer 4

Una diferencia bastante importante es que Boost expresión regular puede apoyar la vinculación a la UCI para soporte Unicode (clases de personajes, etc.) Boost Regex ICU Support.

Por lo que puedo decir, Boost Xpressive no tiene este tipo de soporte incorporado.

Answer 5

Intentaré complementar las respuestas de otras personas profundizando en el tema de las expresiones regulares en tiempo de compilación (CTR) frente a las expresiones regulares en tiempo de ejecución (RTR) de una manera más teórica (este tema está implícito en OP pregunta indirectamente en mi humilde opinión). La expresión regular en tiempo de ejecución es más conocida y popular (la mayoría de las implementaciones de bibliotecas principales de idiomas), supongo que por razones históricas. Están bien cuando la expresión regular se determina en tiempo de ejecución, a diferencia del CTR. Ambos funcionan en base a la máquina de estados finitos.

RTR son "compilados" e interpretados por algún tipo de máquina de estado finito universal (universal significa su tipo de intérprete cuyo esquema se da en tiempo de ejecución, "compilado" en alguna estructura de datos interna - cuando pasa cadena de expresiones regulares, luego interpretado en tiempo de ejecución).

Pero CTR es "compilado" en tiempo de compilación y son particular, específico para expresiones regulares, por lo que no puede usarlos, cuando la expresión regular se da en tiempo de ejecución (aplicaciones como editores de texto, archivo/buscadores de internet) Pero a priori son más eficientes (teóricamente) que la máquina de estado finito en tiempo de compilación personalizada en eficiencia, que el intérprete con esquema preestablecido de tabla de esta máquina (algunos casos similares son acceso de campo de reflexión vs. tiempo de compilación acceso, o función especializada optimizada para algún parámetro fijo como se señala there). Otra ventaja es la comprobación de sintaxis en tiempo de compilación. El CTR se puede implementar a través de metaprogramación y/o generación de código.

En cuanto a las implementaciones específicas, hay muchas RTR, pero no tantas CTR. Para C++ se mencionan las implementaciones de Boost y STL C++ 0x11. Es posible que los necesite para optimizar el rendimiento regex/tamaño del uso generado de código/memoria, principalmente relevante para sistemas integrados o aplicaciones específicas de alto rendimiento. SO question about CTR Encontrar implementaciones de CTR es más difícil, un ejemplo si se encuentra es Re2C Code generator project, Java CTR implementation y C# implementación con compilación en tiempo de ejecución (en código IL, no estructura de datos interna) de Regex [hay ASÍ QUE pregunta]

PS Lo sentimos, no se pudieron publicar algunos enlaces relevantes debido a la reputación