“文件末尾没有换行符” 编译器警告
某些C++编译器出现以下警告的原因是什么？
文件末尾没有换行符
为什么源文件/头文件末尾应该有一个空行？
What is the reason for the following warning in some C++ compilers?
No newline at end of file
Why should I have an empty line at the end of a source/header file?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
想想如果没有换行符可能会出现的一些问题。 根据 ANSI 标准，文件开头的
#include会按原样将文件插入到文件的前面，并且不会在#include. 如果 foo.h 的最后一行是没有换行的注释怎么办？ 现在 foo.cpp 的第一行已被注释掉。 这些只是可能出现的问题类型的几个例子。之后插入新行。 foo.h>在文件内容之后。 因此，如果您在解析器中包含一个末尾没有换行符的文件，则它将被视为 foo.h 的最后一行与 foo 的第一行位于同一行。 cpp只是想向任何感兴趣的人指出詹姆斯下面的回答。 虽然上述答案对于 C 仍然是正确的，但新的 C++ 标准 (C++11) 已更改，因此如果使用 C++ 和符合 C++11 的编译器，则不应再发出此警告。
来自 James 帖子的 C++11 标准：
Think of some of the problems that can occur if there is no newline. According to the ANSI standard the
#includeof a file at the beginning inserts the file exactly as it is to the front of the file and does not insert the new line after the#include <foo.h>after the contents of the file. So if you include a file with no newline at the end to the parser it will be viewed as if the last line offoo.his on the same line as the first line offoo.cpp. What if the last line of foo.h was a comment without a new line? Now the first line offoo.cppis commented out. These are just a couple of examples of the types of problems that can creep up.Just wanted to point any interested parties to James' answer below. While the above answer is still correct for C, the new C++ standard (C++11) has been changed so that this warning should no longer be issued if using C++ and a compiler conforming to C++11.
From C++11 standard via James' post:
“听话”的答案是“因为 C++03 标准说不以换行符结尾的程序的行为是未定义的”（释义）。
好奇的答案就在这里：http://gcc.gnu。 org/ml/gcc/2001-07/msg01120.html。
The answer for the "obedient" is "because the C++03 Standard says the behavior of a program not ending in newline is undefined" (paraphrased).
The answer for the curious is here: http://gcc.gnu.org/ml/gcc/2001-07/msg01120.html.
C++03 标准 [2.1.1.2] 声明：
C++03 Standard [2.1.1.2] declares:
C++11 中删除了每个源文件以非转义换行符结尾的要求。 现在的规范如下：
符合标准的编译器不应再发出此警告（至少在 C++11 模式下编译时不会发出此警告，如果编译器具有针对语言规范的不同修订版的模式）。
The requirement that every source file end with a non-escaped newline was removed in C++11. The specification now reads:
A conforming compiler should no longer issue this warning (at least not when compiling in C++11 mode, if the compiler has modes for different revisions of the language specification).
此警告还可能有助于表明文件可能已被某种方式截断。 确实，编译器无论如何都可能会抛出编译器错误 - 特别是如果它位于函数中间 - 或者可能是链接器错误，但这些可能更神秘，并且不能保证发生。
当然，如果文件在换行符后立即被截断，也不能保证此警告，但它仍然可以捕获其他错误可能错过的某些情况，并对问题给出更强的提示。
This warning might also help to indicate that a file could have been truncated somehow. It's true that the compiler will probably throw a compiler error anyway - especially if it's in the middle of a function - or perhaps a linker error, but these could be more cryptic, and aren't guaranteed to occur.
Of course this warning also isn't guaranteed if the file is truncated immediately after a newline, but it could still catch some cases that other errors might miss, and gives a stronger hint to the problem.
就我而言，我使用 KOTLIN 语言，编译器位于 IntelliJ 上。 另外，我正在使用带有 LINT 的 docker 容器来修复可能存在的打字错误、导入、代码使用等问题。这个错误很可能来自这些 lint 修复 - 我的意思是肯定的。
简而言之，该错误表示“在文件末尾添加新行”就是这样。
之前没有多余的空行：
In my case, I use KOTLIN Language and the compiler is on IntelliJ. Also, I am using a docker container with LINT to fix possible issues with typos, imports, code usage, etc. This error is coming from these lint fixes, most probably - I mean surely.
In short, the error says, 'Add a new line at the end of the file' That is it.
Before there was NO extra empty line:
因为如果文件不以换行符结尾，则 C/C++ 版本之间的行为会有所不同。 尤其令人讨厌的是较旧的 C++ 版本，C++ 03 中的 fx 标准表示（翻译阶段）：
未定义的行为是不好的：符合标准的编译器可以或多或少地执行它想要的操作（插入恶意代码或其他任何内容）——这显然是警告的原因。
虽然 C++11 中的情况更好，但最好避免出现早期版本中未定义行为的情况。 C++03 规范比 C99 更糟糕，C99 完全禁止此类文件（然后定义行为）。
Because the behavior differs between C/C++ versions if file does not end with new-line. Especially nasty is older C++-versions, fx in C++ 03 the standard says (translation phases):
Undefined behavior is bad: a standard conforming compiler could do more or less what it wants here (insert malicous code or whatever) - clearly a reason for warning.
While the situation is better in C++11 it is a good idea to avoid situations where the behavior is undefined in earlier versions. The C++03 specification is worse than C99 which outright prohibits such files (behavior is then defined).
我正在使用 c-free IDE 版本 5.0，在我的程序中，无论是“c++”还是“c”语言，我都遇到了同样的问题。只是在程序末尾，即程序的最后一行（在函数大括号之后，它可以是 main 或任何函数），按 Enter-行号。 将增加1。然后执行相同的程序，它将运行而不会出错。
I am using c-free IDE version 5.0,in my progrm either of 'c++' or 'c' language i was getting same problem.Just at the end of the program i.e. last line of the program(after braces of function it may be main or any function),press enter-line no. will be increased by 1.then execute the same program,it will run without error.
不是特定的 C/C++，而是 C 方言：使用
GL_ARB_shading_language_include扩展时，OS X 上的 glsl 编译器会警告您NOT缺少换行符。 因此，您可以编写一个带有标头保护的MyHeader.h文件，该文件以#endif // __MY_HEADER_H__结尾，并且您将丢失该行之后的行#include "MyHeader.h"当然。not specific C/C++ but a C dialect: when using the
GL_ARB_shading_language_includeextension the glsl compiler on OS X warns you NOT about a missing newline. So you can write aMyHeader.hfile with a header guard which ends with#endif // __MY_HEADER_H__and you will lose the line after the#include "MyHeader.h"for sure.#include会将其行替换为文件的文字内容。 如果文件不以换行符结尾，则包含将其拉入的#include的行将与下一行合并。#includewill replace its line with the literal contents of the file. If the file does not end with a newline, the line containing the#includethat pulled it in will merge with the next line.它不是指空行，而是最后一行（其中可以包含内容）是否以换行符终止。
大多数文本编辑器都会在文件最后一行的末尾添加换行符，因此如果最后一行没有换行符，则存在文件被截断的风险。 但是，您可能不想要换行符是有充分理由的，因此它只是警告，而不是错误。
It isn't referring to a blank line, it's whether the last line (which can have content in it) is terminated with a newline.
Most text editors will put a newline at the end of the last line of a file, so if the last line doesn't have one, there is a risk that the file has been truncated. However, there are valid reasons why you might not want the newline so it is only a warning, not an error.