Intuicyjnie, sądząc ze specyfikacji C++, wygląda na to, że jeśli istream::putback(c)
powinien zawsze ustawiać bufor wejściowy tak, aby następne wywołanie istream::peek()
miało odczytać znak c
. Czy to nie jest poprawne? Pytam, ponieważ najnowsza wersja libC++ shipping z Xcode 4.6 wydaje się nie egzekwować tego zachowania we wszystkich przypadkach - szczególnie, gdy ostatni znak znajduje się w EOF. To samo dotyczy, jeśli używasz unget()
zamiast putback(c)
.Czy nie istream :: peek() zawsze zwraca to, co właśnie odrzuciłeś()?
Czy zachowanie biblioteki libC++ jest poprawne, czy też intuicja tego, jak powinien działać prawidłowo?
Rozważ ten przykładowy kod, który działa z libstdC++, ale nie z libC++ (asercja kończy się niepowodzeniem).
#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;
}
Czy którekolwiek z 'eofbit',' failbit', 'badbit' ustawione po' putback (c) '? (Dla odniesienia: z libstdC++ 4.7, żaden z nich nie jest ustawiony, strumień jest 'dobry()'.) – us2012
+1 do obu odpowiedzi. Wygląda jak błąd w libC++, który został naprawiony w r162608. –