在程序調試過程中發現，有一個程序一直死循環在文件的讀取中。http://tuhao.blogbus.com/logs/21306687.html 從這邊文章瞭解到了相關信息
主要在於eof()不只是讀取文件的最後一個字符，它會接着往後讀取，如果此函數返回ture時，則此時返回的文件結束符0xFF纔是真正的結尾。
具體內容如下：
在使用C/C++讀文件的時候，一定都使用過eof（）這個函數來判斷文件是否爲空或者是否讀到文件結尾了，也會在使用這個函數的過程中遇到一些問題，如不能準確的判斷是否爲空或者是否到了文件尾，以至於有些人可能還會懷疑這個函數是不是本身在設計上就有問題。
先來看看如下這段代碼：
#include <iostream>
#include <fstream>
using namespace std;
int main()
{
char ch = 'x';
ifstream fin("test.txt" /*, ios::binary*/);
if (fin.eof())
{
cout << "file is empty."<<endl;
return 0;
}
while (!fin.eof())
{
fin.get(ch);
cout << ch;
}
system("pause");
return 0;
}
編譯並運行以上代碼，
如果test.txt不存在，程序會形成死循環，fin.eof()永遠返回false，
如果test.txt爲空，程序打印出一個x字符，
當test.txt中存在一字符串“abcd”且沒有換行時，程序打印出“abcdd”，
當存在以上字符串並且有一新的空行時，程序打印出“abcd”加上一空行。
這種現象可能讓很多人很迷惑，程序運行的結果似乎很不穩定，時對時錯。使用binary模式讀時結果一樣。在這裏，大家可能有一個誤區，認爲eof（）返回true時是讀到文件的最後一個字符，其實不然，eof（）返回true時是讀到文件結束符0xFF，而文件結束符是最後一個字符的下一個字符。如下圖所示：
因此，當讀到最後一個字符時，程序會多讀一次（編譯器會讓指針停留在最後一個字符那裏，然後重複讀取一次，這也就是就上面最後一個字符會輸出兩次的原因。至於是不是所有的編譯器都這樣處理我就不太清楚了，我使用的VC6，VC8似乎都是這樣的）
問題出來了，就要找出對應的解決之道，要解決以上的問題，只需要調整一下條件語句即可：
fin.peek() == EOF
或 fin.get(ch)
再來看一下另外一種情況：
#include <iostream>
#include <fstream>
#include <string>
using namespace std;
int main()
{
string str;
ifstream fin("test.txt"/*, ios::binary*/);
if (fin.peek() == EOF)
{
cout << "file is empty."<<endl;
return 0;
}
while (!fin.eof())
{
fin >> str;
cout << str;
}
system("pause");
return 0;
}
上述代碼在VC8下編譯運行，發現，當文件結尾沒有空行時，結果正確，當結尾有空行時，最後一個字符串將被重複輸出一次， 而VC6的情況則有所不同，沒有重複輸出，但輸出了一個空行。
因此，爲了保證在不同的編譯器下得到一致的我們期望的結果，將條件語句做一下修改：
fin >> str
綜上所述，我們可以得到以下結論：
1. 判斷文件是否爲空時使用peek函數，若peek返回EOF則文件爲空；
2. 讀取文件過程中，讀取非char型時，使用peek判斷文件尾將不再適用，循環判斷條件應改用>>操作符進行讀取，若讀入char型緩衝區，peek函數會表現得很好。
以下是其它的一些相關資料，先記着。。
(1) 字節的讀取
在正常的情況下, getc 以 unsigned char 的方式讀取文件流, 擴張爲一個整數,並返
回. 換言之, getc 從文件流中取一個字節, 並加上24個零,成爲一個小於256的整數,
然後返回.
int c;
while ((c = fgetc (rfp))!= -1) // -1就是 EOF
fputc (c, wfp);
上面 fputc 中的 c 雖然是整數, 但在 fputc 將其寫入文件流之前, 又把整數的高24位
去掉了, 因此 fgetc, putc 配合能夠實現文件複製. 到目前爲止, 把 c 定義爲
char仍然是可行的, 但下面我們將看到,把 c 定義爲 int 是爲正確判段文件是否結束.
(2) 判斷文件結束.
多數人認爲文件中有一個EOF,用於表示文件的結尾. 但這個觀點實際上是錯誤的,在文
件所包含的數據中,並沒有什麼文件結束符. 對getc 而言, 如果不能從文件中讀取,
則返回一個整數 -1,這就是所謂的EOF. 返回 EOF 無非是出現了兩種情況,一是文件已
經讀完; 二是文件讀取出錯,反正是讀不下去了.
請注意: 在正常讀取的情況下, 返回的整數均小於256, 即0x0~0xFF. 而讀不出返回的
是 0xFFFFFFFF. 但, 假如你用fputc把 0xFFFFFFFF 往文件裏頭寫, 高24位被屏蔽,寫入的將
是 0xFF. // lixforalpha 請注意這一點
(3) 0xFF 會使我們混淆嗎?
不會, 前提是, 接收返回值的 c 要按原型定義爲 int.
如果下一個讀取的字符將爲 0xFF, 則
int c;
c = fgetc (rfp); // c = 0x000000FF;
if (c != -1) // 當然不等, -1 是 0xFFFFFFFF
fputc (wfp); // 噢, OXFF 複製成功.
字符0xFF, 其本身並不是EOF.
(4) 將 c 定義 char
假定下一個讀取的字符爲 0xFF 則
char c;
c = fgetc (rfp); // fgetc(rfp)的值爲 0x000000FF, 暗中降爲字節, c = 0xFF
if (c != -1) // 字符與整數比較? c 被帶符號(signed)擴展爲0xFFFFFFFF, 喔噢,
條件成立,文件複製提前退出.
while ((c=fgetc(rfp))!=EOF) 中的判別條件成立, 文件複製結束! 意外中止.
(5) 將 c 定義爲 unsigned char;
當讀到文件末尾, 返回 EOF 也就是 -1 時,
unsigned char c;
c = fgetc (rfp); // fgetc (rfp)的值爲EOF,即-1,即0xFFFFFFFF, 降格爲字節, c=0xFF
if ( c!= -1) // c 被擴展爲 0x000000FF, 永遠不回等於 0xFFFFFFFF
所以這次雖然能正確複製 0xFF, 但卻不能判斷文件結束. 事實上,在 c 爲 uchar 時,
c != -1 是永遠成立的, 一個高質量的編譯器, 比如 gcc會在編譯時指出這一點.
(6) 爲何需要feof?
FILE *fp;
fp 指向一個很複雜的數據結構, feof 是通過這個結構中的標誌來判斷文件是否結束的.
如果文件用 fgetc 讀取, 剛好把最後一個字符讀出時, fp 中的EOF標誌不會打開,這時
用feof判斷,將會得到文件尚未結束的結論.
fgetc 返回 -1 時, 我們仍無法確信文件已經結束, 因爲可能是讀取錯誤! 這時我們
需要 feof 和 ferror.