Estoy tratando de usar std :: regex en un código de C ++ 11, pero parece que el soporte tiene algunos errores. Un ejemplo:
#include <regex>
#include <iostream>
int main (int argc, const char * argv[]) {
std::regex r("st|mt|tr");
std::cerr << "st|mt|tr" << " matches st? " << std::regex_match("st", r) << std::endl;
std::cerr << "st|mt|tr" << " matches mt? " << std::regex_match("mt", r) << std::endl;
std::cerr << "st|mt|tr" << " matches tr? " << std::regex_match("tr", r) << std::endl;
}
salidas:
st|mt|tr matches st? 1
st|mt|tr matches mt? 1
st|mt|tr matches tr? 0
cuando se compila con gcc (MacPorts gcc47 4.7.1_2) 4.7.1, ya sea con
g++ *.cc -o test -std=c++11
g++ *.cc -o test -std=c++0x
o
g++ *.cc -o test -std=gnu++0xAdemás, la expresión regular funciona bien si solo tengo dos patrones alternativos, por ejemplo st|mt, por lo que parece que el último no coincide por algunas razones. El código funciona bien con el compilador LLVM de Apple.
¿Alguna idea sobre cómo solucionar el problema?
Actualizar una posible solución es utilizar grupos para implementar múltiples alternativas, por ejemplo (st|mt)|tr.
<regex>soporte de libstdc ++ es incompleto. En que te podemos ayudarregexlibstdc ++, consulte gcc.gnu.org/onlinedocs/libstdc++/manual/…<regex>en los últimos 3-4 años (como en: permanece sin implementar).<regex>lo proporciona libstdc ++ (la biblioteca estándar de GCC) y nogcc(la interfaz del compilador), es parte de GCC (el proyecto). Consulte "libstdc ++ - v3 se ha desarrollado y lanzado como parte de GCC" . Si su distribución elige dividirlo en un paquete separado, eso no tiene nada que ver con GCC.Respuestas:
<regex>fue implementado y lanzado en GCC 4.9.0.En su versión (anterior) de GCC, no está implementado .
Ese
<regex>código prototipo se agregó cuando todo el soporte de C ++ 0x de GCC era altamente experimental, rastreaba los primeros borradores de C ++ 0x y estaba disponible para que las personas experimentaran. Eso permitió a la gente encontrar problemas y dar retroalimentación al comité de estándares antes de que se finalizara el estándar. En el momento muchas personas estaban agradecidos de tener acceso a tenido borde de la sangría cuenta mucho antes de C ++ 11 fue terminado y antes de que muchos otros compiladores proporcionan ningún apoyo, y que realmente ayudó a mejorar la retroalimentación C ++ 11. Esto fue algo bueno TM .El
<regex>código nunca estuvo en un estado útil, pero se agregó como un trabajo en progreso como muchos otros bits de código en ese momento. Se registró y se puso a disposición de otros para que colaboraran si así lo deseaban, con la intención de que finalmente se terminara.A menudo, así es como funciona el código abierto: lanzamiento temprano, lanzamiento frecuente ; desafortunadamente, en el caso de
<regex>que solo hicimos bien la parte inicial y no la parte frecuente que habría terminado la implementación.La mayoría de las partes de la biblioteca estaban más completas y ahora están casi completamente implementadas, pero
<regex>no lo habían sido, por lo que permaneció en el mismo estado sin terminar desde que se agregó.No fue tan mala idea hace unos años, cuando C ++ 0x todavía era un trabajo en progreso y enviamos muchas implementaciones parciales. Nadie pensó que permanecería inutilizable durante tanto tiempo, así que, en retrospectiva, tal vez debería haberse deshabilitado y requerir una macro o una opción de tiempo de compilación para habilitarlo. Pero ese barco zarpó hace mucho tiempo. Hay símbolos exportados de libstdc ++. Así que la biblioteca depende del código de expresiones regulares, por lo que simplemente eliminarlo (en, digamos, GCC 4.8) no habría sido trivial.
fuente
Detección de características
Este es un fragmento para detectar si la
libstdc++implementación se implementa con el preprocesador C define:Macros
_GLIBCXX_REGEX_DFS_QUANTIFIERS_LIMITse define enbits/regex.tccen4.9.x_GLIBCXX_REGEX_STATE_LIMITse define enbits/regex_automatron.hen5+_GLIBCXX_RELEASEse agregó7+como resultado de esta respuesta y es la versión principal de GCCPruebas
Puedes probarlo con GCC así:
Resultados
A continuación se muestran algunos resultados de varios compiladores:
Aquí hay dragones
Esto es totalmente incompatible y se basa en la detección de macros privadas que los desarrolladores de GCC han colocado en los
bits/regex*encabezados. Podían cambiar y desaparecer en cualquier momento . Con suerte, no se eliminarán en las versiones actuales 4.9.x, 5.x, 6.x, pero podrían desaparecer en las versiones 7.x.Si los desarrolladores de GCC agregaron un
#define _GLIBCXX_HAVE_WORKING_REGEX 1(o algo, una sugerencia, una sugerencia, un empujón) en la versión 7.x que persistió, este fragmento podría actualizarse para incluirlo y las versiones posteriores de GCC funcionarían con el fragmento anterior.Por lo que yo sé, todos los otros compiladores tienen un trabajo
<regex>cuando__cplusplus >= 201103L, pero tu caso es distinto.Obviamente, esto se rompería por completo si alguien definiera las macros
_GLIBCXX_REGEX_DFS_QUANTIFIERS_LIMITo_GLIBCXX_REGEX_STATE_LIMITfuera de losstdc++-v3encabezados.fuente
_GLIBCXX_REGEX_IS_OK_NOW_KTHXBAIen los encabezados, para que no se olvide, ¡gracias!En este momento (usando std = c ++ 14 en g ++ (GCC) 4.9.2) todavía no acepta regex_match.
Aquí hay un enfoque que funciona como regex_match pero usando sregex_token_iterator en su lugar. Y funciona con g ++.
imprimirá 1 2 3
puede leer la referencia sregex_token_iterator en: http://en.cppreference.com/w/cpp/regex/regex_token_iterator
fuente
std::regex_searchembargo, puede hacerlo con , consulte wandbox.org/permlink/rLbGyYcYGNsBWsaB