seekg 제로는 GCC 4.6.2 <code>istream.tcc</code>에 따르면 EOF 플래그

를 재설정 : seekg 제로는 GCC 4.6.2 <code>istream.tcc</code>에 따르면 EOF 플래그

basic_istream<_CharT, _Traits>:: 
seekg(off_type __off, ios_base::seekdir __dir) 
{ 
    // _GLIBCXX_RESOLVE_LIB_DEFECTS 
    // DR60. Do not change _M_gcount. 
    // Clear eofbit per N3168. 
    this->clear(this->rdstate() & ~ios_base::eofbit);

가 실수로이 충돌 - 나는 무한 while (!eof) 루프를 얻는 이유를 알아낼 수 없었다. 기본적으로 seekg가 0 길이로 호출 될 때 - 당신은 여전히 eof reset을 얻습니다. std::ios_base_::cur 길이가 0 인 경우에도 eof 비트를 재설정해야 할 이유가 있습니까? 이것은 VC10/11에서 발생하지 않습니다.

N3168이란 무엇입니까?

출처

2012-02-27 Nick

eof()을 악용하는 것이 문제입니다.이 플래그의 유일한 용도는 파일의 끝에 도달했기 때문에 마지막으로 읽지 못했는지 확인하는 것입니다. if eof()이 설정되어 있어도 실제 원인이 아닐 수도 있습니다). 스트림 상태가 bool로 변환을 사용하여 확인하려면 : 당신은 여전히 읽기가 성공하면 읽은 후 확인해야

while (in) ...

참고.

N3168은 표준화위원회에서 논의한 논문입니다. 오프 - 핸드 (off-hand) 나는 그것이 국가 신체 결함 보고서에 대한 반응이라는 것을 넘어서 어떤 특별한 주제가 논의되는지를 모른다.

출처

2012-02-27 13:32:38

N3168의 동기는 정상적으로,'eofbit'이 설정되면, 모든 추가 작업이 실패 할 것이 요구됩니다. 즉, 파일의 끝까지 읽으면,'eof'를 지우지 않고 이전의 지점으로 되돌아 갈 수 없다는 것을 의미합니다. "수정"은 찾기 기능이 다른 것을 시도하기 전에'eofbit '을 재설정하도록 요구하는 것입니다. 물론, 입력이 실패한 경우, 탐색하기 전에 여전히이 문제를 해결해야합니다. 따라서이 문제는 매우 희귀합니다 (파일 끝에있는 정수를 입력하고 후행 공백없이 검색 한 후). –

그러나'ios_base :: cur'에서'0' 오프셋을 가진 seekg-ing은 이론상 효과가 없습니다. 또는 seekg가 호출 된 후에는 'pos'값에 관계없이 항상 진행되는 또 다른 이유가 있습니다. – Nick

현재 위치를 탐색하는 주요 용도는 스트림을 읽기 또는 쓰기 용으로 변경할 수있는 상태로 변경하는 것입니다. 또한 탐색은 위치를 변경하기위한 것이므로 스트림이 끝이 아닐 수도 있다고 가정하는 것이 합리적입니다. 필자는 그 논문을 보지 않았지만,'failbit'을 잠재적으로 삭제하는 변경을 포함하고 있습니다. 대부분의 작업이 실패 할 때까지 설정되어있는 한. –

seekg 제로는 GCC 4.6.2 <code>istream.tcc</code>에 따르면 EOF 플래그

답변

관련 문제