Caracteres extraídos por istream >> doble
Código de muestraen Coliru:
#include <iostream>
#include <sstream>
#include <string>
int main()
{
double d; std::string s;
std::istringstream iss("234cdefipxngh");
iss >> d;
iss.clear();
iss >> s;
std::cout << d << ", '" << s << "'\n";
}
Estoy leyendo N3337 aquí (presumiblemente eso es lo mismo que C ++ 11). En [istream.formatted.arithmetic] tenemos (parafraseado):
operator>>(double& val);
Como en el caso de los insertadores, estos extractores dependen del objeto num_get <> (22.4.2.1) del entorno local para realizar el análisis de los datos del flujo de entrada. Estos extractores se comportan como funciones de entrada formateadas (como se describe en 27.7.2.2.1). Después de construir un objeto centinela, la conversión se produce como si fuera realizada por el siguiente fragmento de código:
typedef num_get< charT,istreambuf_iterator<charT,traits> > numget;iostate err = iostate::goodbit;use_facet< numget >(loc).get(*this, 0, *this, err, val);setstate(err);
Mirando hacia 22.4.2.1:
Los detalles de esta operación ocurren en tres etapas.
- Etapa 1: determinar un especificador de conversión
- Etapa 2: extraiga caracteres de in y determine un valor de char correspondiente para el formato esperado por la especificación de conversión determinada en la etapa 1.
- Etapa 3: resultados de la tienda
En la descripción de la Etapa 2, es demasiado largo para que pegue todo aquí. Sin embargo, dice claramente que todos los caracteres deben extraerse antes de intentar la conversión; y además que se deben extraer exactamente los siguientes caracteres:
cualquiera de0123456789abcdefxABCDEFX+-El localdecimal_point()El localthousands_sep()Finalmente, las reglas para la Etapa 3 incluyen:
- Para un valor de coma flotante, la funciónstrtold.
El valor numérico a almacenar puede ser uno de:
- cero, si la función de conversión no puede convertir todo el campo.
Todo esto parece especificar claramente que la salida de mi código debe ser0, 'ipxngh'. Sin embargo, en realidad produce algo más.
¿Es este un error del compilador / biblioteca? ¿Hay alguna disposición que esté pasando por alto para que un entorno local cambie el comportamiento de la Etapa 2? (Enotra pregunta alguien publicó un ejemplo de un sistema que realmente extrae los caracteres, pero también extraeipxn que no están en la lista especificada en N3337).
Como señaló Perreal, este texto de la Etapa 2 es relevante:
Si el descarte es verdadero, entonces si "." Aún no se ha acumulado, entonces se recuerda la posición del personaje, pero de lo contrario se ignora al personaje. De lo contrario, si "." Ya se ha acumulado, el personaje se descarta y la Etapa 2 termina. Si no se descarta, se realiza una verificación para determinar sic se permite como el siguiente carácter de un campo de entrada del especificador de conversión devuelto por la Etapa 1. Si es así, se acumula.
Si el personaje se descarta o se acumula, ++ in avanza por ++ in y el procesamiento vuelve al comienzo de la etapa 2.
Por lo tanto, la Etapa 2 puede terminar si el carácter está en la lista de caracteres permitidos, pero no es un carácter válido para%g. No dice exactamente, pero presumiblemente esto se refiere a la definición defscanf de C99, que permite:
y también
En otro lugar que no sea el "C", se pueden aceptar formularios de secuencia de temas específicos del lugar adicionales.
Entonces, en realidad la salida de Coliru es correcta; y de hecho el procesamientodebe Intente validar la secuencia de caracteres extraídos hasta ahora como una entrada válida para%g, mientras extrae cada personaje.
Siguiente pregunta: ¿está permitido, como en el hilo al que me vinculé anteriormente, aceptari , n, p etc en la etapa 2?
Estos son caracteres válidos para%g , sin embargo, no están en la lista de átomos que la Etapa 2 puede leer (es decir,c == 0 para mi última cita, entonces el personaje no se descarta ni se acumula).