"copia de carbono" a C++ istream?

Question

Por mi propio marco pequeño analizador, estoy tratando de definir (algo así como) la siguiente función:

template <class T> 
// with operator>>(std::istream&, T&) 
void tryParse(std::istream& is, T& tgt) 
{ 
    is >> tgt /* , *BUT* store every character that is consumed by this operation 
    in some string. If afterwards, is.fail() (which should indicate a parsing 
    error for now), put all the characters read back into the 'is' stream so that 
    we can try a different parser. */ 
} 

entonces podría escribir algo como esto: (quizás no es el mejor ejemplo)

/* grammar: MyData  = <IntTriple> | <DoublePair> 
      DoublePair = <double> <double> 
      IntTriple = <int> <int> <int> */ 
class MyData 
{ public: 
    union { DoublePair dp; IntTriple it; } data; 
    bool isDoublePair; 
}; 

istream& operator>>(istream& is, MyData& md) 
{ 
    /* If I used just "is >> md.data.it" here instead, the 
     operator>>(..., IntTriple) might consume two ints, then hit an 
     unexpected character, and fail, making it impossible to read these two 
     numbers as doubles in the "else" branch below. */ 
    tryParse(is, md.data.it); 
    if (!is.fail()) 
     md.isDoublePair = false; 
    else 
    { 
     md.isDoublePair = true; 
     is.clear(); 
     is >> md.data.dp; 
    } 
    return is; 
} 

Cualquier ayuda es muy apreciada.

Answer 1

Desafortunadamente, las transmisiones solo tienen un soporte de retorno muy simple y rudimentario.

Las últimas veces que necesité esto, escribí mis propias clases de lectores que incluían una secuencia, pero tenía un búfer para volver a poner las cosas y leer de la transmisión solo cuando ese búfer está vacío. Estas tenían formas de obtener un estado, y usted podría comprometer un estado o revertir a un estado anterior.
La acción predeterminada en el destructor de la clase de estado era retrotraerse, de forma que pudiera analizar más adelante sin pensar demasiado en el manejo de errores, porque una excepción simplemente revertiría el estado del analizador hasta un punto donde se intentó una regla gramatical diferente. (Creo que esto se llama retroceder.) Aquí hay un boceto:

class parse_buffer { 
    friend class parse_state; 
public: 
    typedef std::string::size_type index_type; 

    parse_buffer(std::istream& str); 

    index_type get_current_index() const; 
    void set_current_index(index_type) const; 

    std::string get_next_string(bool skip_ws = true) const; 
    char get_next_char(bool skip_ws = true); 
    char peek_next_char(bool skip_ws = true); 

    std::string get_error_string() const; // returns string starting at error idx 
    index_type get_error_index() const; 
    void set_error_index(index_type); 

    bool eof() const; 

    // ... 
}; 

class parse_state { 
public: 
    parse_state(parse_buffer&); 
    ~parse_state(); 

    void commit(); 
    void rollback(); 

    // ... 
}; 

Esto debería hacerte una idea. No tiene ninguna implementación, pero fue sencillo y debería ser fácil de rehacer. Además, el código real tenía muchas funciones convenientes como leer funciones que leen una cadena delimitada, consumir una cadena si era una de varias palabras clave determinadas, leer una cadena y convertirla a un tipo dado por parámetro de plantilla, y cosas como esta.

La idea era que una función establezca el índice de error en su posición inicial, guarde el estado de análisis e intente analizar hasta que tenga éxito o se ejecute en un callejón sin salida. En este último caso, lanzaría una excepción. Esto destruiría los objetos parse_state en la pila, reduciendo el estado hasta una función que podría detectar la excepción y probar algo más, o emitir un error (que es donde entra get_error_string())

Si quieres un Analizador realmente rápido, esta estrategia puede ser incorrecta, pero a menudo las transmisiones también se ralentizan. OTOH, la última vez que utilicé algo así, hice un analizador XPath que opera en un DOM propietario, que se usa para representar escenas en un renderizador 3D.Y fue no el analizador XPath que obtuvo todo el calor de los chicos tratando de obtener mayores velocidades de cuadro. :)

Answer 2

Esto no es para lo que están destinadas las transmisiones. Debería leer los datos que desea analizar en un búfer y luego transferir ese búfer (preferiblemente como un rango de iterador) a las funciones que lo analizan. Esto podría ser algo como esto:

template <class T, class U> 
bool tryParse(U & begin, U & end, T & target) { 
    // return true if parse was successful, false otherwise 
} 

Para leer de un istream en un búfer, se puede utilizar un istream_iterator:

std::vector<char> buffer(std::istream_iterator<char>(is), std::istream_iterator<char>()); 

Esto lee toda la corriente en el vector cuando se crea.

Answer 3

Poner los personajes de vuelta es complicado. Algunas transmisiones admiten unget() y putback(somechar), pero no hay garantía de cuántos caracteres puede perder (si corresponde).

Una manera más confiable es leer los caracteres en un búfer y analizarlos, o almacenar los caracteres leídos en el primer intento de análisis y usar ese búfer al analizar por segunda vez.

Answer 4

Puede hacer algunas cosas interesantes con streambuf miembros de transmisión. En particular, tiene acceso directo a los punteros de los buffers.

Sin embargo, no tiene garantía sobre el tamaño de los buffers.