偶然發(fā)現(xiàn)一個用了STL很久都沒有發(fā)現(xiàn)的問題，特記之。
事情的起因很簡單，需要做一些簡單的重構(gòu)，將原來讀文件得到二進(jìn)制緩沖數(shù)據(jù)的部分分離開，拉一個單獨(dú)的API，接收文件二進(jìn)制內(nèi)容的緩沖區(qū)參數(shù)；估計(jì)很多人都會做這樣的事情，將一個小程序變得更有用，不得不把300行的main拆開來，露幾個函數(shù)來用。
其他的部分都如想象般的簡單，唯獨(dú)在測試原有讀文件調(diào)用新接口的地方卡住了。
原來的邏輯如此這般：
FILE* fin = open("file.bin", "rb");
if (fin == NULL)
{
exit(-1);
}
unsigned char buf[65536] = {0};
char ch;
int i = 0;
while ( (ch = fgetc(fin)) != EOF)
{
buf[i++] = ch;
if (i >= sizeof(buf))
exit(-2);
}
//..................改寫后的調(diào)用接口如下：
typedef std::vector<unsigned char> BinaryBufferType;
int SomeFunc(BinaryBufferType& buf, ...)
為了完成接口測試并且還原原有功能，需要將文件內(nèi)容讀入到一個vector中來測試。初始的想法如下：
ifstream ifs("file.bin", ios::in|ios::binary);
if (!ifs.good())
{
exit(-1);
}
typedef std::istream_iterator<char> FsIt;
BinaryBufferType buf;
std::copy(FsIt(ifs), FsIt(), std::back_inserter(buf));
除了出錯檢查，重要的部分就是一個copy調(diào)用將STL流的內(nèi)容自動拷貝到vector里邊；這是一個很典型的例子，乃至SGI的文檔里邊關(guān)于copy算法的例子就是這樣的。
問題是，這個代碼卻是有問題的，和上邊的C代碼并不等價，實(shí)際測試的過程中，發(fā)現(xiàn)居然漏掉了3個Byte的數(shù)據(jù)。
頓時感覺很奇怪了，馬上GDB跟了下，由于數(shù)據(jù)太多，一下子沒看出來那個出書丟了（后來發(fā)現(xiàn)是0c）；想想是否與binary方式有關(guān)呢，已經(jīng)采用binary方式讀入了呀？
Google一番才發(fā)現(xiàn)有人遇到了同樣的問題，原來 stream_iterator 默認(rèn)采用的是formatted I/O方式處理數(shù)據(jù)，所以某些東西會被跳過。
如果需要拷貝二進(jìn)制數(shù)據(jù)，該采用如下的法子：
typedef std::istreambuf_iterator<char> FsIt;
BinaryBufferType buf;
std::copy(FsIt(buf.rdbuf()), FsIt(), std::back_inserter(buf));
就是這點(diǎn)小小的差別，以前一直被忽略了…… 浪費(fèi)了不少時間，當(dāng)時如果搜索istreambuf_iterator，似乎能發(fā)現(xiàn)Effective STL里邊講述過這個，可惜當(dāng)時看的時候，很快過去，
居然一點(diǎn)印象都沒有？
真是“絕知此事要躬行”了。