使用feof()来控制读取循环有什么问题？例如：
#include <stdio.h>
#include <stdlib.h>
int
main(int argc, char **argv)
{
char *path = "stdin";
FILE *fp = argc > 1 ? fopen(path=argv[1], "r") : stdin;
if( fp == NULL ){
perror(path);
return EXIT_FAILURE;
}
while( !feof(fp) ){ /* THIS IS WRONG */
/* Read and process data from file… */
}
if( fclose(fp) != 0 ){
perror(path);
return EXIT_FAILURE;
}
return EXIT_SUCCESS;
}
这个循环有什么问题？
while(!feof)是错误的，因为它测试了一些无关紧要的东西并且无法测试你需要知道的东西。结果是您错误地执行了假设它正在访问已成功读取的数据的代码，而实际上这从未发生过。
我想提供一个抽象的、高层次的观点。因此，如果您对while(!feof)实际操作感兴趣，请继续阅读。
I/O 操作与环境交互。环境不是您程序的一部分，也不受您的控制。环境真正与您的程序“同时”存在。与所有并发事件一样，关于“当前状态”的问题没有意义：并发事件之间没有“同时性”的概念。状态的许多属性根本不会同时存在。
让我更准确地说：假设你想问，“你有更多数据吗”。您可以询问并发容器或您的 I/O 系统。但答案通常是不可操作的，因此毫无意义。那么如果容器说“是”怎么办——当你尝试阅读时，它可能不再有数据了。同样，如果答案是“否”，那么当您尝试阅读时，数据可能已经到达。结论是，有没有像“我有数据”这样的属性，因为您无法对任何可能的答案做出有意义的行动。（缓冲输入的情况稍微好一些，你可能会得到一个“是的，我有数据”构成某种保证，但你仍然必须能够处理相反的情况。输出情况肯定和我描述的一样糟糕：你永远不知道那个磁盘或那个网络缓冲区是否已满。）
因此我们得出结论，询问 I/O 系统是否能够执行 I/O 操作是不可能的，实际上也是不合理的。我们可以与之交互的唯一可能方式（就像与并发容器一样）是尝试操作并检查它是成功还是失败。在您与环境交互的那一刻，只有那时您才能知道交互是否实际上是可能的，此时您必须承诺执行交互。（如果您愿意，这是一个“同步点”。）
现在我们到了EOF。EOF 是您从尝试的I/O 操作中获得的响应。这意味着您正在尝试读取或写入某些内容，但是这样做时您未能读取或写入任何数据，而是遇到了输入或输出的结尾。基本上所有 I/O API 都是如此，无论是 C 标准库、C++ iostream 还是其他库。只要 I/O 操作成功，您根本无法知道未来的操作是否会成功。您必须始终先尝试操作，然后再响应成功或失败。
在每个示例中，请仔细注意，我们首先尝试 I/O 操作，然后在结果有效时使用结果。进一步注意，我们总是必须使用 I/O 操作的结果，尽管结果在每个示例中采用不同的形状和形式。
C stdio，从文件中读取：
for (;;) {
size_t n = fread(buf, 1, bufsize, infile);
consume(buf, n);
if (n == 0) { break; }
}
我们必须使用的结果是n，被读取的元素数量（可能少到零）。
C标准输入法，scanf：
for (int a, b, c; scanf("%d %d %d", &a, &b, &c) == 3; ) {
consume(a, b, c);
}
我们必须使用的结果是 的返回值scanf，即转换的元素数。
C++、iostreams 格式化提取：
for (int n; std::cin >> n; ) {
consume(n);
}
我们必须使用的结果是std::cin它本身，它可以在布尔上下文中进行评估，并告诉我们流是否仍处于good()状态。
C ++，iostreams getline：
for (std::string line; std::getline(std::cin, line); ) {
consume(line);
}
我们必须使用的结果是再次std::cin，就像以前一样。
POSIX，write(2)刷新缓冲区：
char const * p = buf;
ssize_t n = bufsize;
for (ssize_t k = bufsize; (k = write(fd, p, n)) > 0; p += k, n -= k) {}
if (n != 0) { /* error, failed to write complete buffer */ }
我们在这里使用的结果是k，写入的字节数。这里的重点是，我们只能知道写入操作后写入了多少字节。
POSIXgetline()
char *buffer = NULL;
size_t bufsiz = 0;
ssize_t nbytes;
while ((nbytes = getline(&buffer, &bufsiz, fp)) != -1)
{
/* Use nbytes of data in buffer */
}
free(buffer);
我们必须使用的结果是nbytes，直到并包括换行符的字节数（如果文件没有以换行符结尾，则为 EOF）。
请注意，-1当发生错误或到达 EOF 时，该函数显式返回（而不是 EOF！）。
您可能会注意到我们很少拼出实际的单词“EOF”。我们通常以我们更感兴趣的其他方式检测错误条件（例如，未能执行我们想要的尽可能多的 I/O）。在每个示例中，都有一些 API 功能可以明确地告诉我们遇到了 EOF 状态，但这实际上并不是一条非常有用的信息。它比我们经常关心的细节要多得多。重要的是 I/O 是否成功，而不是如何失败。
实际查询 EOF 状态的最后一个示例：假设您有一个字符串，并且想要测试它是否代表一个整数，除了空格之外，最后没有额外的位。使用 C++ iostreams，它是这样的：
std::string input = " 123 "; // example
std::istringstream iss(input);
int value;
if (iss >> value >> std::ws && iss.get() == EOF) {
consume(value);
} else {
// error, "input" is not parsable as an integer
}
我们在这里使用两个结果。首先是iss流对象本身，以检查格式化提取是否value成功。但是，在消耗了空格之后，我们执行了另一个 I/O/ 操作，iss.get()并期望它作为 EOF 失败，如果整个字符串已经被格式化提取消耗了，就会出现这种情况。
在 C 标准库中，您可以strto*l通过检查结束指针是否已到达输入字符串的末尾来实现与函数类似的功能。
这是错误的，因为（在没有读取错误的情况下）它进入循环的次数比作者预期的多一次。如果出现读取错误，则循环永远不会终止。
考虑以下代码：
/* WARNING: demonstration of bad coding technique!! */
#include <stdio.h>
#include <stdlib.h>
FILE *Fopen(const char *path, const char *mode);
int main(int argc, char **argv)
{
FILE *in;
unsigned count;
in = argc > 1 ? Fopen(argv[1], "r") : stdin;
count = 0;
/* WARNING: this is a bug */
while( !feof(in) ) { /* This is WRONG! */
fgetc(in);
count++;
}
printf("Number of characters read: %u\n", count);
return EXIT_SUCCESS;
}
FILE * Fopen(const char *path, const char *mode)
{
FILE *f = fopen(path, mode);
if( f == NULL ) {
perror(path);
exit(EXIT_FAILURE);
}
return f;
}
该程序将始终打印比输入流中的字符数大一的字符（假设没有读取错误）。考虑输入流为空的情况：
$ ./a.out < /dev/null
Number of characters read: 1
在这种情况下，feof()在读取任何数据之前调用它，因此它返回 false。循环进入，fgetc()被调用（并返回EOF），并且计数增加。然后feof()调用并返回 true，导致循环中止。
在所有此类情况下都会发生这种情况。 直到对流的读取遇到文件结尾之后feof()才会返回 true 。的目的不是检查下一次读取是否会到达文件末尾。的目的是确定先前读取函数的状态，并区分错误情况和数据流结束。如果返回 0，则必须使用/来确定是否发生错误或是否消耗了所有数据。同样，如果返回。 仅在fread 返回零或返回后才有用。在此之前，将始终返回 0。feof()feof()fread()feofferrorfgetcEOFfeof()fgetcEOFfeof()
在调用 之前，总是需要检查读取的返回值（anfread()或 anfscanf()或 an ） 。fgetc()feof()
更糟糕的是，考虑发生读取错误的情况。在这种情况下，fgetc()返回EOF，feof()返回 false，并且循环永远不会终止。在所有使用的情况下while(!feof(p))，必须至少在循环内检查 for ferror()，或者至少应该将 while 条件替换为while(!feof(p) && !ferror(p))或者存在无限循环的非常真实的可能性，可能会喷出各种垃圾作为正在处理无效数据。
所以，总而言之，虽然我不能肯定地说，永远不会有这样的情况，在这种情况下，写“ while(!feof(f))”在语义上是正确的（尽管必须在循环内进行另一次检查，并用中断来避免读取错误时的无限循环)，几乎可以肯定它总是错误的。即使出现了一个正确的案例，它也是惯用的错误，以至于它不是编写代码的正确方法。任何看到该代码的人都应该立即犹豫并说，“这是一个错误”。并且可能打作者（除非作者是你的老板，在这种情况下建议谨慎。）
不，这并不总是错误的。如果您的循环条件是“当我们没有尝试读取文件末尾时”，那么您使用while (!feof(f)). 然而，这不是一个常见的循环条件 - 通常你想测试其他东西（例如“我可以阅读更多”）。while (!feof(f))没有错，只是用错了。
feof()指示是否已尝试读取文件末尾。这意味着它几乎没有预测效果：如果它是真的，你确定下一个输入操作会失败（你不确定前一个失败 BTW），但如果它是假的，你不确定下一个输入操作操作会成功。此外，输入操作可能会因文件结尾以外的其他原因而失败（格式化输入的格式错误、纯 IO 故障——磁盘故障、网络超时——对于所有输入类型），所以即使你可以预测文件结尾（任何尝试实现 Ada one 的人都会告诉你，如果你需要跳过空格，它会很复杂，并且它对交互式设备有不良影响——有时会强制输入下一个在开始处理前一行之前的行），
所以C中正确的习语是以IO操作成功为循环条件进行循环，然后测试失败的原因。例如：
while (fgets(line, sizeof(line), file)) {
/* note that fgets don't strip the terminating \n, checking its
presence allow to handle lines longer that sizeof(line), not showed here */
...
}
if (ferror(file)) {
/* IO failure */
} else if (feof(file)) {
/* format error (not possible with fgets, but would be with fscanf) or end of file */
} else {
/* format error (not possible with fgets, but would be with fscanf) */
}
feof()不是很直观。以我的拙见，如果任何读取操作导致到达文件末尾，FILE则应将 's end-of-file 状态设置为。true相反，您必须在每次读取操作后手动检查是否已到达文件末尾。例如，如果使用以下命令从文本文件中读取，这样的事情将起作用fgetc()：
#include <stdio.h>
int main(int argc, char *argv[])
{
FILE *in = fopen("testfile.txt", "r");
while(1) {
char c = fgetc(in);
if (feof(in)) break;
printf("%c", c);
}
fclose(in);
return 0;
}
如果这样的东西可以代替，那就太好了：
#include <stdio.h>
int main(int argc, char *argv[])
{
FILE *in = fopen("testfile.txt", "r");
while(!feof(in)) {
printf("%c", fgetc(in));
}
fclose(in);
return 0;
}