沒有具體測(cè)試過，fwrite用于寫結(jié)構(gòu)、二進(jìn)制數(shù)組，可以參考w.r.stevens在apue(5.9, p145)中關(guān)于fwrite的描述。  回復(fù)  更多評(píng)論
  

fread和fwrite是C標(biāo)準(zhǔn)庫， Read/WriteFile是Windows API。
如果不需要HANLDE的特殊功能， 使用fread/fwrite的代碼可以不加修改的移植到其他平臺(tái)去。

參數(shù)用于錯(cuò)誤處理。

T a[count];
if ( count != fread(a, sizeof a[0], count, stream) ) {
// error
}

if ( count != READ(a, sizeof a, stream )/sizeof a[0] ) {
// error
}
  回復(fù)  更多評(píng)論
  

@OwnWaterloo
我是說它參數(shù)里頭的 elementSize 和 count，應(yīng)該合并成一個(gè)，沒必要分成兩個(gè)  回復(fù)  更多評(píng)論
  

@OwnWaterloo
直接傳入需要讀取的字節(jié)數(shù)，傳出已成功讀取的字節(jié)數(shù)  回復(fù)  更多評(píng)論
  

@溪流
下面的READ就是按你說的方式設(shè)計(jì)的。
你覺得用著方便嗎？
  回復(fù)  更多評(píng)論
  

@OwnWaterloo
下面的好。可是為什么上面的當(dāng)初要那樣設(shè)計(jì)呢？  回復(fù)  更多評(píng)論
  

@溪流
呃。。。 下面不是還要做一次除法么。。。
  回復(fù)  更多評(píng)論
  

@OwnWaterloo
不理解
我的意思是，fread應(yīng)該這樣：
int fread(FILE *file, unsigned char *buffer, int bufferSize);
返回已讀取的字節(jié)數(shù)
哪里來的一個(gè)size加有一個(gè)count  回復(fù)  更多評(píng)論
  

@溪流
憑什么只能是unsigned char*呢？
  回復(fù)  更多評(píng)論
  

@OwnWaterloo
void * 也行
讀寫文件我應(yīng)該知道要讀/寫多少字節(jié)吧？原先的第二個(gè)參數(shù)可以固定為1  回復(fù)  更多評(píng)論
  

@溪流
你想得太狹隘了。

仔細(xì)看2樓的例子。 T非得是char嗎？
a非得是數(shù)組嗎？

T a[1]; 可以嗎？
T v;可以嗎？
  回復(fù)  更多評(píng)論
  

@OwnWaterloo
T a[count];
if ( count != fread(a, sizeof a[0], count, stream) ) {
// error
}

T a[count];
ReadFile(hFile, a, sizeof(a), ...);
這樣多明確啊！  回復(fù)  更多評(píng)論
  

@溪流
2樓仔細(xì)看。 我懶得說了。
  回復(fù)  更多評(píng)論
  

@OwnWaterloo
看不來了，你解釋一下吧
我不要返回count，返回bytesRead就行了  回復(fù)  更多評(píng)論
  

@溪流
你不需要不等于別人不需要……

你完全將ReadFile或者fread當(dāng)作"字節(jié)流讀取"來使用了。
實(shí)際上，fread不僅僅可以用來讀取字節(jié)流；
還可以用來讀取"二進(jìn)制格式存放的數(shù)據(jù)"， 比如上面的T。

  回復(fù)  更多評(píng)論
  

@OwnWaterloo
本來就是字節(jié)流嘛
“二進(jìn)制格式存放的數(shù)據(jù)”，無非也就是多少個(gè)字節(jié)而已。
1個(gè)T就是 sizeof(T) 個(gè) byte  回復(fù)  更多評(píng)論
  

@溪流
讀出半個(gè)T怎么辦？
還沒看懂2樓的代碼？
  回復(fù)  更多評(píng)論
  

@OwnWaterloo
那應(yīng)該告訴我讀了 sizeof(T)/2 個(gè)字節(jié)，而不是告訴我讀了 0 個(gè) T 啊  回復(fù)  更多評(píng)論
  

不知道二樓的代碼有什么精妙之處，，請(qǐng)解釋下。。。。
T a[count];
if ( count != fread(a, sizeof a[0], count, stream) ) {
// error
}

這段完全可以寫成：
T a[count];
if ( bytes != fread(a, 1, (sizeof a[0]) * count, stream) ) {
// error
}
么，而且能夠知道到底讀了多少，半個(gè)T，1/4個(gè)T，都可以精確表示出來
  回復(fù)  更多評(píng)論
  

@溪流
>>那應(yīng)該告訴我讀了 sizeof(T)/2 個(gè)字節(jié)，而不是告訴我讀了 0 個(gè) T 啊

你已經(jīng)形成思維定勢(shì)了：
1. fread應(yīng)該設(shè)計(jì)成什么樣子， 你心中已經(jīng)有答案
2. fread如果設(shè)計(jì)成那樣子我會(huì)怎么用， 你已經(jīng)習(xí)慣這么用
3. 應(yīng)為我習(xí)慣這么用， 所以fread設(shè)計(jì)成這樣就是不對(duì)的

這是循環(huán)論證， 說明不了任何問題。


現(xiàn)在你要拋棄你的習(xí)慣：
習(xí)慣1： 不僅僅用來讀取字節(jié)流， 還可以直接讀取二進(jìn)制格式文件
習(xí)慣2： 有返回值檢測(cè)


然后比較兩段代碼， 看哪段寫著順手：

void f(T* buf, size_t buf_size, FILE* stream)
{
size_t count = fread(buf, sizeof *buf, buf_size, stream);
for (size_t i=0; i<count; ++i)
process(buf[i ] );
}

void g(T* buf, size_t buf_size, FILE* stream)
{
size_t bytes = Read(buf, sizeof(T) * buf_size, stream);
for (size_t i=0; i< bytes/ sizoef(T); ++i)
process( buf[i ] );
}
  回復(fù)  更多評(píng)論
  

@OwnWaterloo
Read 那一句我習(xí)慣第二段的。
不錯(cuò)，是讀取二進(jìn)制文件格式，文件格式應(yīng)該已經(jīng)知曉了。何謂知曉？就是知道它每一個(gè)字節(jié)是干啥的，所以精確到每個(gè)字節(jié)不帶來壞處。

假如有個(gè)文件頭（為討論方便，請(qǐng)忽略對(duì)齊問題）
struct T
{
BYTE sign[10];
DWORD headerSize;
。。。
}

你是寫成 read(buf, sizeof(T), 1, stream) 呢，還是寫成 read(buf, 1, sizeof(T), stream) 呢？還是覺得這個(gè) 1 是多余的？

按你說的最小設(shè)計(jì)原則，不用 elememtSize * count 的形式，直接精確到字節(jié)，現(xiàn)有的任務(wù)都可以完成。而搞成 elementSize * count 的形式，在挺大一部分的例子中，有個(gè)參數(shù)是多余的。那么，這個(gè)設(shè)計(jì)不是很失敗么？

第一點(diǎn)，我不覺得“字節(jié)流”與“二進(jìn)制文件”有什么區(qū)別
第二點(diǎn)，要返回值檢測(cè)，不至于我連讀到哪兒了都不知道  回復(fù)  更多評(píng)論
  

2樓說的即是  回復(fù)  更多評(píng)論
  

古時(shí)候人們讀的是struct不是char，所以純粹是為了增加可讀性……  回復(fù)  更多評(píng)論
  

恩 我其實(shí)覺得 也沒有必要有2個(gè)參數(shù)
size 和 count


反正都是讀size*count個(gè)。

反正我沒有看懂，OwnWaterloo 說的理由。

  回復(fù)  更多評(píng)論
  

@溪流
對(duì)， 你說得對(duì)。
fread確實(shí)干了多余的事情。

調(diào)用時(shí)那個(gè)乘法無所謂， 要么就是調(diào)用者自己做， 要么就是fread做。
問題出在返回時(shí)那個(gè)除法上。 fread總會(huì)做一個(gè)除法， 對(duì)很多情況是不需要的。
而不使用乘／除法實(shí)現(xiàn)的fread又需要大量的循環(huán)。
  回復(fù)  更多評(píng)論
  

@溪流
跟"最小接口"與"人本接口"沒什么關(guān)系。
相對(duì)于read_int, read_string, 這兩種設(shè)計(jì)都可以算是最小接口。


為了不降低"實(shí)現(xiàn)優(yōu)化的潛力"， 保留適當(dāng)?shù)男畔?duì)實(shí)現(xiàn)是有用的。
比如malloc vs calloc。
用戶端的信息原本是 sizeof(elem) 和 count兩個(gè)。
calloc會(huì)將信息繼續(xù)帶到下層。
而malloc將這個(gè)信息丟掉了。

這可能就會(huì)影響malloc的某種優(yōu)化， 比如對(duì)齊策略。
1. 分配12個(gè)char的數(shù)組
2. 分配12/sizeof(int)個(gè)數(shù)組
對(duì)malloc來說， 它接受到的都是12bytes， 已經(jīng)無法區(qū)分這兩者的不同。
malloc始終返回的是該平臺(tái)下有最嚴(yán)格對(duì)齊的內(nèi)存。

而calloc就可以明確知道每個(gè)元素的大小， 可以利用這個(gè)信息， 計(jì)算出該種大小的所有類型在該平臺(tái)下的最嚴(yán)格對(duì)齊需求，就可以少填充一些。

當(dāng)然， calloc不一定會(huì)使用這個(gè)信息進(jìn)行優(yōu)化， 但它保有這個(gè)優(yōu)化的潛力。
（calloc另一個(gè)memset的行為就很惡心了）


而read， 沒想出可以利用size和count進(jìn)行優(yōu)化的方法。
而且將這2個(gè)參數(shù)分開， 同時(shí)又要避免返回時(shí)那個(gè)除法的話， 還會(huì)顯得不夠統(tǒng)一。
  回復(fù)  更多評(píng)論
  

同意@OwnWaterloo 的看法。
還是2個(gè)參數(shù)確定讀取字節(jié)數(shù)比較好。  回復(fù)  更多評(píng)論
  

你不覺得把讀取的每個(gè)單位的尺寸和單位數(shù)分開可讀性更高么？一個(gè)函數(shù)調(diào)用的實(shí)參中出現(xiàn)了乘法，第一眼看上去肯定會(huì)覺得費(fèi)解。

而且往高里說這是個(gè)設(shè)計(jì)理念問題，作為一個(gè)接口，讓用戶越少思考越好。

sizeof(XXX) * count = 總字節(jié)數(shù)，這是你想出來的，想這個(gè)問題難道不需要費(fèi)力么？  回復(fù)  更多評(píng)論
  

@欲三更
有什么費(fèi)力的？都到讀寫文件的關(guān)口了，難道幾個(gè)字節(jié)你都不想弄清楚？
另，你喜歡寫成 fread(buf, sizeof(T), 1, stream) 呢，還是 fread(buf, 1, sizeof(T), stream) 呢？每次我都為這個(gè)問題糾結(jié)好久。  回復(fù)  更多評(píng)論
  

@溪流
你這個(gè)問題很好解決~
找個(gè)現(xiàn)代點(diǎn)的ide...
  回復(fù)  更多評(píng)論
  

參數(shù)設(shè)計(jì)的很好啊，一個(gè)數(shù)據(jù)塊的單位大小，一個(gè)是要讀取多少個(gè)數(shù)據(jù)塊，返回讀取成功的數(shù)據(jù)塊數(shù)目。這個(gè)設(shè)計(jì)很好呀。你可以嘗試作為一個(gè)整塊式的讀取。  回復(fù)  更多評(píng)論
  

@欲三更
如果連這個(gè)代碼的意思都看不懂那還是不要寫代碼算了！！！  回復(fù)  更多評(píng)論
  

@溪流
看來你也是個(gè)完美主義者，當(dāng)然是fread(buf, sizeof(T), 1, fp)咯，這才是這個(gè)函數(shù)接口的本意。但我也覺得這個(gè)參數(shù)有點(diǎn)多余！！！  回復(fù)  更多評(píng)論
  

@C++愛好者
呵呵。重新回顧了上面這么多糾結(jié)的提法（塊啊、字節(jié)流啊、二進(jìn)制格式啊、struct啊，char啊），再看到你說明白話，頓感輕松。塊也好、二進(jìn)制格式也好、struct也好，不就是一堆字節(jié)么。。。  回復(fù)  更多評(píng)論
  

正好要用，謝謝  回復(fù)  更多評(píng)論