刚学习C语言读取文件的时候,可能都遇到过这个“bug”,读到末尾时数据有重复。
解决方案也是五花八门,甚至有人把数据先缓存了,再忽略掉最后一组....
不妨看一段代码,两种解决方案,猜猜看,究竟哪一个方案是正确的。
/*
*方案一:先判断,后读取
*/
while(!feof(fp)) {
fread(buf, 1, 100, fp);
//do_some_thing
}
/*
*方案二:先读取,后判断
*/
while(1) {
fread(buf, 1, 100, fp);
if(feof(fp))
break;
//do_some_thing
}
/*
*方案一:先判断,后读取
*/
while (!feof(fp)) {
fread(buf, 1, 100, fp);
//do_some_thing
}
/*
*方案二:先读取,后判断
*/
while (1) {
fread(buf, 1, 100, fp);
if (feof(fp))
break;
//do_some_thing
}
曾经,我毫不犹豫的选择一,过了不久又毫不犹豫的选择二。然而,非常遗憾,没有
一个是正确的。暂不解释why,来一段MSDN上的代码,关于feof的一个example:
#include
#include
intmain(void)
{
intcount, total = 0;
charbuffer[100];
FILE*stream;
fopen_s( &stream,"crt_feof.txt","r");
if( stream == NULL )
exit( 1 );
// Cycle until end of file reached:
while( !feof( stream ) )
{
// Attempt to read in 100 bytes:
count = fread( buffer,sizeof(char), 100, stream );
if( ferror( stream ) ) {
perror("Read error");
break;
}
// Total up actual bytes read
total += count;
}
printf("Number of bytes read = %d/n", total );
fclose( stream );
}
#include
#include
int main( void )
{
int count, total = 0;
char buffer[100];
FILE *stream;
fopen_s( &stream, "crt_feof.txt", "r" );
if( stream == NULL )
exit( 1 );
// Cycle until end of file reached:
while( !feof( stream ) )
{
// Attempt to read in 100 bytes:
count = fread( buffer, sizeof( char ), 100, stream );
if( ferror( stream ) ) {
perror( "Read error" );
break;
}
// Total up actual bytes read
total += count;
}
printf( "Number of bytes read = %d/n", total );
fclose( stream );
}
不要惊讶,你没看错,MSDN是先使用feof,然后再读取,跟网上的看法有些出入。
到底是为什么呢?我觉得,还是从feof和fread的源码开始分析比较好,实现可能不同,用法应该是一致的。以GLIBC 2.10的源码为例。不管是 unlocked 还是 非unlocked,feof最终还是调
用了unlocked的那个_IO_feof_unlocked“函数”,所以分析该“函数”即可。
#define _IO_feof_unlocked(__fp) (((__fp)->_flags & _IO_EOF_SEEN) != 0)
#define _IO_feof_unlocked(__fp) (((__fp)->_flags & _IO_EOF_SEEN) != 0)
现在可以得到一个结论:
feof的返回值,仅仅取决于文件结构是否被打上 _IO_EOF_SEEN 标志。
feof本身并不影响这个标志,因此可以断定,标志是在读取的时候被修改的,于是
去追寻fread的源码。经历了宏的泥淖,欣赏了纯C填虚函数表模拟C++多态的壮
烈,终于找到了fread的背后黑手。fread实际上可能调用不同的函数,mmap文件
和普通文件的处理,是不一样的,不过知道其中一个便可,因为底层的差异,对程
序员是透明的,只要展示给程序员看的一面是一致的就OK。且看关键部分代码:
count = _IO_SYSREAD (fp, s, count);
if(count <= 0)
{
if(count == 0)
fp->_flags |= _IO_EOF_SEEN;
else
fp->_flags |= _IO_ERR_SEEN;
break;
}
count = _IO_SYSREAD (fp, s, count);
if (count <= 0)
{
if (count == 0)
fp->_flags |= _IO_EOF_SEEN;
else
fp->_flags |= _IO_ERR_SEEN;
break;
}
看到_IO_SYSREAD有什么感觉呢? 哦,你可以把它当成表现跟read系统调用一样
的东西,返回值大于0,就是实际读取字节数;等于0,就是文件之前已被读完(或者
是文件根本就是空的),本次没读到数据;小于0就是失败,有错误发生。
总结代码中的流程和细节,整理出来就是:
标准IO是带有缓存的,每一次请求,未必对应一次系统调用
缓存剩余字节数大于等于请求的,直接使用缓存,不产生系统调用
fread当且仅当,系统调用读取到的字节数为0时,才会打上结束标志
feof只检查_IO_EOF_SEEN标志位,不做其它影响返回值的判断
根据这些,不难得出以下结论:
文件全部读完,即使缓存用尽且SYS_READ读尽,feof未必返回真值
SYS_READ实际读取到0字节的事情发生后,feof一定返回真值
fread实际读取的字节数少于预期时,feof一定返回真值
feof可以只检查标志就做出判断,而fread可能多一次系统调用才知道结束
feof返回0的时候,上一次读取的数据,一定是有效数据
至此,已经不难理解,为什么最上面贴的两种方案都是错的。因为它们都没有对
fread的返回值做出反应,如果对这个返回值加以处理,无论是先读后判断还是先
判断后读取,都是没有问题的,都能得到正确的结果。当然,这得有个前提,就是
除了feof外,有别的方法判断是否结束,倘若如fgetc那般,读取的字符作为函数返
回值,读二进制文件时,就无法判断了,因为二进制文件本身也可能含有EOF字符。
这种情况,只有一种方案,就是先读取,再用feof判断是否结束。
做了那么长时间的铺垫,现在回到本文的核心。是先读取还是先判断?我认为:
在决定用哪一种方案前,首先要考虑用于读取的那个函数的返回值的意义
如果你不想了解细节,也不屑于些许性能,一律先读取后判断,肯定不会有错
如果读取函数的返回值蕴含是否读取成功,那么先判断后读取,可能更加高效
但是有一点,不管是哪种方式,如果用于读取的函数,返回值包含读取是否成功或者实际 读取字节数等信息,这个信息是一定要考虑的。同样,写入操作也好,其它操作也好,只 要函数带有返回值,且未注明这个返回值没有意义,都应该认真推敲下这个返回值的意义, 然后决定是否需要处理这个返回值。