文件末尾没有换行符;编译器警告

它指的不是空行，而是最后一行(其中可以包含内容)是否以换行符结束。

大多数文本编辑器会在文件最后一行的末尾放置换行符，因此如果最后一行没有换行符，则存在文件被截断的风险。但是，有合理的理由不需要换行符，因此它只是一个警告，而不是一个错误。

“服从”的答案是“因为c++ 03标准说，不以换行符结束的程序的行为是未定义的”(转述)。

好奇的答案在这里:http://gcc.gnu.org/ml/gcc/2001-07/msg01120.html。

#include将用文件的文字内容替换它的行。如果文件不以换行符结束，则包含将其拉入的#include的行将与下一行合并。

想想如果没有换行符可能会出现的一些问题。根据ANSI标准，文件开头的#include将文件完全插入到文件的前面，而不是在文件内容之后的#include <foo.h>之后插入新行。因此，如果你在解析器中包含一个结尾没有换行符的文件，它将被视为foo.h的最后一行与foo.cpp的第一行在同一行。如果foo.h的最后一行是没有新行的注释呢?现在foo.cpp的第一行被注释掉了。这些只是可能会出现的问题类型的几个例子。

只是想让感兴趣的人看看詹姆斯下面的答案。虽然上述答案对于C仍然正确，但新的c++标准(c++ 11)已经更改，因此如果使用c++和符合c++ 11的编译器，则不应再发出此警告。

来自c++ 11标准的James的帖子:

一个非空的源文件，如果它不是以换行符结尾，或者在任何这样的拼接发生之前以紧接在反斜杠字符前的换行符结尾，将被当作附加了一个换行符来处理(c++ 11§2.2/1)。

c++ 03标准[2.1.1.2]声明:

< p >…如果一个非空的源文件不以换行符结束，或者以换行符结束 在任何这样的拼接发生之前，紧跟着一个反斜杠字符，行为是未定义的

这不是错误。这只是一个警告。

在编辑器中打开文件，转到文件的最后一行，并按enter键在文件末尾添加空行。

不过，除此之外，你应该使用#include <iostream>而不是<iostream.h>。然后在后面加上using std::cout;。

在c++ 11中删除了每个源文件以非转义换行符结束的要求。现在的规范是:

一个非空的源文件，如果它不是以换行符结尾，或者在任何这样的拼接发生之前以紧接在反斜杠字符前的换行符结尾，将被当作附加了一个换行符来处理(c++ 11§2.2/1)。

符合标准的编译器应该不再发出此警告(至少在c++ 11模式下编译时不会，如果编译器具有针对语言规范不同版本的模式)。

此警告还可能有助于指示文件可能以某种方式被截断。的确，编译器无论如何都可能抛出编译器错误——尤其是在函数中间时——或者可能抛出链接器错误，但这些错误可能更加神秘，而且不保证会发生。

当然，如果文件在换行符之后立即被截断，这个警告也不能保证，但它仍然可以捕捉到其他错误可能遗漏的一些情况，并对问题给出更强的提示。

我使用的是c-free IDE 5.0版本，在我的程序中，无论是“c++”还是“c”语言，我都遇到了同样的问题。只有在节目的最后，即程序的最后一行(在function的大括号之后，它可以是main函数或任何函数)，按回车键-line no。会增加1。然后执行相同的程序，它将正常运行。

当然，在实际操作中，每个编译器都会在#include之后添加新行。值得庆幸的是。——@mxcl

不是特定的C/ c++，而是C方言:当使用GL_ARB_shading_language_include扩展时，OS X上的glsl编译器会警告你不缺少换行符。因此，你可以编写一个带有以#endif // __MY_HEADER_H__结尾的头保护的MyHeader.h文件，而你将肯定会失去#include "MyHeader.h"之后的行。

因为如果文件不以new-line结束，则在C/ c++版本之间的行为是不同的。尤其令人讨厌的是旧的c++版本，在c++ 03的标准中说(翻译阶段):

如果一个非空的源文件不以换行结束 字符，或以紧接在前面的换行字符结束

.

.

未定义行为是不好的:符合标准的编译器在这里或多或少可以做它想做的事情(插入恶意代码或其他)——这显然是警告的理由。

虽然这种情况在c++ 11中更好，但最好避免在早期版本中行为未定义的情况。c++ 03规范比C99更糟糕，C99完全禁止这样的文件(然后定义行为)。

在我的情况下，我使用KOTLIN语言和编译器是IntelliJ。此外，我正在使用一个带有LINT的docker容器来修复拼写、导入、代码使用等可能的问题。这个错误是来自这些lint修复，最有可能-我的意思是肯定。

简而言之，错误会说“在文件末尾添加新行”。

.

在没有多余的空行之前:

.