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++0x

Ademá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> 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ó.

Sin embargo, en serio, ¿quién pensó que enviar una implementación de regex_search que solo "devuelve falso" fue una buena idea?

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.

Detección de características

Este es un fragmento para detectar si la libstdc++implementación se implementa con el preprocesador C define:

#include <regex>
#if __cplusplus >= 201103L &&                             \
    (!defined(__GLIBCXX__) || (__cplusplus >= 201402L) || \
        (defined(_GLIBCXX_REGEX_DFS_QUANTIFIERS_LIMIT) || \
         defined(_GLIBCXX_REGEX_STATE_LIMIT)           || \
             (defined(_GLIBCXX_RELEASE)                && \
             _GLIBCXX_RELEASE > 4)))
#define HAVE_WORKING_REGEX 1
#else
#define HAVE_WORKING_REGEX 0
#endif

Macros

• _GLIBCXX_REGEX_DFS_QUANTIFIERS_LIMITse define en bits/regex.tccen4.9.x
• _GLIBCXX_REGEX_STATE_LIMITse define en bits/regex_automatron.hen5+
• _GLIBCXX_RELEASEse agregó 7+como resultado de esta respuesta y es la versión principal de GCC

Pruebas

Puedes probarlo con GCC así:

cat << EOF | g++ --std=c++11 -x c++ - && ./a.out
#include <regex>

#if __cplusplus >= 201103L &&                             \
    (!defined(__GLIBCXX__) || (__cplusplus >= 201402L) || \
        (defined(_GLIBCXX_REGEX_DFS_QUANTIFIERS_LIMIT) || \
         defined(_GLIBCXX_REGEX_STATE_LIMIT)           || \
             (defined(_GLIBCXX_RELEASE)                && \
             _GLIBCXX_RELEASE > 4)))
#define HAVE_WORKING_REGEX 1
#else
#define HAVE_WORKING_REGEX 0
#endif

#include <iostream>

int main() {
  const std::regex regex(".*");
  const std::string string = "This should match!";
  const auto result = std::regex_search(string, regex);
#if HAVE_WORKING_REGEX
  std::cerr << "<regex> works, look: " << std::boolalpha << result << std::endl;
#else
  std::cerr << "<regex> doesn't work, look: " << std::boolalpha << result << std::endl;
#endif
  return result ? EXIT_SUCCESS : EXIT_FAILURE;
}
EOF

Resultados

A continuación se muestran algunos resultados de varios compiladores:

$ gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ ./a.out
<regex> doesn't work, look: false

$ gcc --version
gcc (GCC) 6.2.1 20160830
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ ./a.out
<regex> works, look: true

$ gcc --version
gcc (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ ./a.out
<regex> works, look: true

$ gcc --version
gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ ./a.out
<regex> works, look: true

$ gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ ./a.out
<regex> works, look: true

$ gcc --version
gcc (GCC) 6.2.1 20160830
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ clang --version
clang version 3.9.0 (tags/RELEASE_390/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ ./a.out  # compiled with 'clang -lstdc++'
<regex> works, look: true

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 los stdc++-v3encabezados.

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 ++.

string line="1a2b3c";
std::regex re("(\\d)");
std::vector<std::string> inVector{
    std::sregex_token_iterator(line.begin(), line.end(), re, 1), {}
};

//prints all matches
for(int i=0; i<inVector.size(); ++i)
    std::cout << i << ":" << inVector[i] << endl;

imprimirá 1 2 3

puede leer la referencia sregex_token_iterator en: http://en.cppreference.com/w/cpp/regex/regex_token_iterator