EOF 是 End Of File 的缩写。
在 C 语言中，它是在标准库中定义的一个宏。
人们经常误认为 EOF 是从文件中读取的一个字符(牢记)。其实，EOF 不是一个字符，它被定义为是 int 类型的一个负数（比如 -1）。EOF 也不是文件中实际存在的内容。EOF 也不是只表示读文件到了结尾这一状态（这种状态可以用 feof() 来检测），它还能表示 I/O 操作中的读、写错误（通常可以用 ferror() 来检测）以及其它一些关联操作的错误状态。
先看文件流。
运行结果：（这里，getline读到}+EOF，已经将文件结束标志位置为1,循环中调用infile.eof()时，自然返回true,跳出循环，}没有进行输出。）
如果写成:
运行结果：
关于while()循环两种写法的感悟：(若文件只有一行，文件结束符在新行)
第二种写法：
读一行，读到最后一个x结束，会进行读的第二次循环（读的内容为空）。
xxxxxxx xx xx
EOF （一般程序生成的文件会将EOF放在新行的开头（由于向文件中输入endl），因此才有读的二次循环操作）
v (文件指针,读完一行后指向这里,位置指针虽然到达EOF，但此时并不能判断文件是否结束，因为只有主动去进行置位，infile.eof()才能返回为真（文件结束）。
那么什么时候会置位？不是位置指针指向eof时，而是读的过程中，读（碰）到了eof才去置位，即不读不知道)
第一种写法：
若eof在新的开头，那么能进行全部输出。
我们做些小更改：
这说明了将文件结束位置位，（就算不用eof()方法返回布尔值），也能作为条件判断。
若新行开头即EOF,不会进入循环。但会将line置空。
若只有32行（}+EOF形式）,也会进入循环，并且执行循环体内容。 当然了，line最终还是}。
再看一种情况：
*getline();无论是cin，还是文件流，都是可以读全空行的。
对标准输入：
先看下面代码:
是否觉得，cin与文件流对EOF的处理是一样的？
后者不必多说，前者并不是识别了EOF才结束的循环，而是输入数据错误导致循环退出，这期间文件结束标志位一直是0，且[ctrl+Z]还被作为特殊字符存在输入缓冲区中。不会被处理。（看最后一个例子，有所补充）
对于cin来讲，输入[ctrl+Z]前有空格，然后直接回车，这是作为文件结束符传入。（更严格，往下看最后一个例子。）
看下例：
while判断语句中逗号运算符后半句可以省去，进行相同的输入时，结果是一致的。也即结束状态置位就可判断条件真假，不必调用cin.eof（）函数(但是却不知道是什么原因导致的循环结束。更具体的写法看最后一个例子。)。
笔者不由想到是不是由于文件流中使用了getline方法，才导致，文本+EOF变得可识别与处理呢。于是采用了getline与cin结合进行测试，经过测试并不是由于getline函数
改变了他们对EOF的处理方式（getline返回值就是相对应的流），本来就有所区别。
此外getline文件流和cin读取时，当直接读到EOF时（在新行），处理方式也不同，文件会读入空到字符串中,改变字符串内容，而cin变量并不会受到cin（EOF）的影响: （string类型也是一样的。下面是int a）
当然了，经测试，如果输入的一串英文，那么也是会对变量的值有所影响的。
当对cin采用getline的时候，它和getline文件流处理在新行的EOF相同：都会将值传入变量中，下例：
cin输入范例：
cin输入文件结束符要求严格： 换行符+【ctrl+Z】 + 换行符才万无一失。请看：
while(流>>变量)：
定义文件输入流in，in与cin在读全新一行的EOF时，不会进入循环，并不会将空值读入变量，
然而，getline(in, text)与 getline(cin, txt)在读全新一行的EOF时，不会进入循环，会将空值传入变量。
文件流与getline文件流当遇到在文本结尾处的EOF时，会将结束符标志置位。这次循环有效，下次不会进入循环，且不会将空值传入变量。
