user-0 提问: [新人求助]下面这段代码第二次运行的结果为什么会是1!!

回复:
user: user-1
content: 11楼的解释很好，又学到了。

user: user-0
content: 引用 11 楼 northwesternwind 的回复:[quote=引用 8 楼 coderCold 的回复:] [quote=引用 7 楼 user-3 的回复:] 例如一个文件只有一个字符 他的内容是 ’1‘，0xFF,0xFF 这是16Bits系统文本文件的结构 或者‘1’，0xFF,0xFF,0xFF,0xFF 如今也许是这个样子 文件指针指向‘1’ 即0x33的时候，文件并没有结束 只有指向0xFF这个位置的时候，feof 才会报告文件结束 写文件的时候，除非出错，永远是可写的，所以永远不会是文件结束位置。 只有读文件，fseek 等操作，才会遇到文件结束。 我明白了,但是这些还不能解释我提出的那个问题.根据我的理解: 假设是8Bits文本文件结构 第一次运行后内容是:'1',0xFF 第二次运行时文件指针指向'1',ReadChar读到了'1',之后文件指针后移到0xFF,然后写入一个字符'2',这是文件内容应该变为'1','2',0xFF 可是我运行的结果显示文件内容还是'1'[/quote] 难倒我了。研究半天才发现原因，这是VC特有的特征，在linux上结果会不一样, MSDN的帮助： 当指定 "r+","w+", 或 "a+" 访问类型时，允许读取和写入。（文件将处于打开状态以进行“更新”。） 但是，当你从读取切换到写入时，输入操作必须遇到 EOF 标记。如果没有 EOF，必须使用对文件定位函数的干预调用。文件定位函数是 fsetpos、fseek 和 rewind。从写入切换到读取时，必须使用对 fflush 或文件定位函数的干预调用。 如果你检查fputc返回值，会发现第二次fputc其实是执行失败了，返回值为-1。 [/quote] 真棒!谢谢~

user: user-2
content: 引用 8 楼 coderCold 的回复:[quote=引用 7 楼 user-3 的回复:] 例如一个文件只有一个字符 他的内容是 ’1‘，0xFF,0xFF 这是16Bits系统文本文件的结构 或者‘1’，0xFF,0xFF,0xFF,0xFF 如今也许是这个样子 文件指针指向‘1’ 即0x33的时候，文件并没有结束 只有指向0xFF这个位置的时候，feof 才会报告文件结束 写文件的时候，除非出错，永远是可写的，所以永远不会是文件结束位置。 只有读文件，fseek 等操作，才会遇到文件结束。 我明白了,但是这些还不能解释我提出的那个问题.根据我的理解: 假设是8Bits文本文件结构 第一次运行后内容是:'1',0xFF 第二次运行时文件指针指向'1',ReadChar读到了'1',之后文件指针后移到0xFF,然后写入一个字符'2',这是文件内容应该变为'1','2',0xFF 可是我运行的结果显示文件内容还是'1'[/quote] 难倒我了。研究半天才发现原因，这是VC特有的特征，在linux上结果会不一样, MSDN的帮助： 当指定 "r+","w+", 或 "a+" 访问类型时，允许读取和写入。（文件将处于打开状态以进行“更新”。） 但是，当你从读取切换到写入时，输入操作必须遇到 EOF 标记。如果没有 EOF，必须使用对文件定位函数的干预调用。文件定位函数是 fsetpos、fseek 和 rewind。从写入切换到读取时，必须使用对 fflush 或文件定位函数的干预调用。 如果你检查fputc返回值，会发现第二次fputc其实是执行失败了，返回值为-1。

user: user-0
content: 引用 9 楼 jackydi 的回复:应该是没有清除输入缓冲区的问题吧，getchar()之后是否应该使用fflush()清除一下输入缓冲区呢？ 是这样吗? ReadChar(fp); fflush(fp); PutChar(fp); 结果还是不对.

user: user-1
content: 应该是没有清除输入缓冲区的问题吧，getchar()之后是否应该使用fflush()清除一下输入缓冲区呢？

user: user-0
content: 引用 7 楼 user-3 的回复:例如一个文件只有一个字符 他的内容是 ’1‘，0xFF,0xFF 这是16Bits系统文本文件的结构 或者‘1’，0xFF,0xFF,0xFF,0xFF 如今也许是这个样子 文件指针指向‘1’ 即0x33的时候，文件并没有结束 只有指向0xFF这个位置的时候，feof 才会报告文件结束 写文件的时候，除非出错，永远是可写的，所以永远不会是文件结束位置。 只有读文件，fseek 等操作，才会遇到文件结束。 我明白了,但是这些还不能解释我提出的那个问题.根据我的理解: 假设是8Bits文本文件结构 第一次运行后内容是:'1',0xFF 第二次运行时文件指针指向'1',ReadChar读到了'1',之后文件指针后移到0xFF,然后写入一个字符'2',这是文件内容应该变为'1','2',0xFF 可是我运行的结果显示文件内容还是'1'

user: user-3
content: 例如一个文件只有一个字符 他的内容是 ’1‘，0xFF,0xFF 这是16Bits系统文本文件的结构 或者‘1’，0xFF,0xFF,0xFF,0xFF 如今也许是这个样子 文件指针指向‘1’ 即0x33的时候，文件并没有结束 只有指向0xFF这个位置的时候，feof 才会报告文件结束 写文件的时候，除非出错，永远是可写的，所以永远不会是文件结束位置。 只有读文件，fseek 等操作，才会遇到文件结束。

user: user-0
content: 引用 5 楼 user-3 的回复:写文件永远也不会到文件结束 除非fseek 读才会到文件结束 文件结束标志读出来以后，文件就结束了，否则还没有 还是没懂,拜托能更详细的讲解一下吗

user: user-3
content: 写文件永远也不会到文件结束 除非fseek 读才会到文件结束 文件结束标志读出来以后，文件就结束了，否则还没有

user: user-0
content: 引用 3 楼 northwesternwind 的回复:[quote=引用 2 楼 coderCold 的回复:] [quote=引用 1 楼 northwesternwind 的回复:] 第一次运行后文件中已经有个1了. 用r+打开从头开始读，所以第二次运行后文件内容应该是1和2。 问题就是按照理解第二次运行后文件的内容是1和2,但是实际跑下来的结果却只有1.[/quote] 开始时候文件是空，还是有一个空行或者空格？应该和这个有关系。但第二次结果应该会 出现2的情况，不会是只有1。[/quote] 第一次文件里面是什么都没有,没有空行和空格.

user: user-2
content: 引用 2 楼 coderCold 的回复:[quote=引用 1 楼 northwesternwind 的回复:] 第一次运行后文件中已经有个1了. 用r+打开从头开始读，所以第二次运行后文件内容应该是1和2。 问题就是按照理解第二次运行后文件的内容是1和2,但是实际跑下来的结果却只有1.[/quote] 开始时候文件是空，还是有一个空行或者空格？应该和这个有关系。但第二次结果应该会 出现2的情况，不会是只有1。

user: user-0
content: 引用 1 楼 northwesternwind 的回复:第一次运行后文件中已经有个1了. 用r+打开从头开始读，所以第二次运行后文件内容应该是1和2。 问题就是按照理解第二次运行后文件的内容是1和2,但是实际跑下来的结果却只有1.

user: user-2
content: 第一次运行后文件中已经有个1了. 用r+打开从头开始读，所以第二次运行后文件内容应该是1和2。