Intuitivamente, a giudicare dalle specifiche C++, mi sembra che istream::putback(c)
debba sempre organizzare il buffer di input in modo tale che la prossima chiamata a istream::peek()
debba leggere il carattere c
. Non è corretto? Chiedo perché l'ultima versione di libC++ di spedizione con Xcode 4.6 sembra non applicare questo comportamento in tutti i casi, in particolare quando l'ultimo carattere è in EOF. Lo stesso vale se si utilizza unget()
anziché putback(c)
.Non dovrebbe istream :: peek() restituire sempre ciò che hai appena messo()?
Il comportamento di libC++ è corretto oppure il mio intuito su come putback()/unget()
dovrebbe funzionare correttamente?
Considerare questo codice di esempio, che funziona con libstdC++ ma non con libC++ (l'asserzione fallisce).
#include <sstream>
#include <cassert>
int main(int argc, const char * argv[])
{
std::istringstream in("[Test]");
while(in)
{
int c = in.get();
if(c == ']')
{
in.putback(c);
assert(in.peek() == c); // Fails with libc++. Succeeds with libstdc++.
break;
}
}
return 0;
}
C'è uno di 'eofbit',' failbit', 'badbit' impostato dopo' putback (c) '? (Per riferimento: con libstdC++ 4.7, nessuno di questi è impostato, lo stream è 'good()'.) – us2012
+1 a entrambe le risposte. Sembra un bug in libC++ corretto in r162608. –