Предупреждение компилятора “Нет новой строки в конце файла”

Question

В чем причина следующего предупреждения в некоторых компиляторах C ++?

Нет новой строки в конце файла

Почему у меня должна быть пустая строка в конце исходного / заголовочного файла?

Answer 1

Подумайте о некоторых проблемах, которые могут возникнуть при отсутствии новой строки.В соответствии со стандартом ANSI #include файла в начале вставляет файл точно таким, какой он есть, в начало файла и не вставляет новую строку после #include <foo.h> после ознакомления с содержимым файла.Таким образом, если вы добавите файл без перевода строки в конце в анализатор, он будет рассматриваться как последняя строка foo.h находится на той же строке, что и первая строка foo.cpp.Что, если последняя строка foo.h была комментарием без новой строки?Теперь первая строка foo.cpp закомментирован.Это всего лишь пара примеров типов проблем, которые могут возникнуть.

---

Просто хотел указать всем заинтересованным сторонам на приведенный ниже ответ Джеймса.Хотя приведенный выше ответ по-прежнему верен для C, новый стандарт C ++ (C ++ 11) был изменен таким образом, что это предупреждение больше не должно выдаваться при использовании C ++ и компилятора, соответствующего C ++ 11.

Из стандарта C ++ 11 через сообщение Джеймса:

Исходный файл, который не является пустым и который не заканчивается символом новой строки или который заканчивается символом новой строки, которому непосредственно предшествует символ обратной косой черты перед любым таким объединением, должен обрабатываться так, как если бы к файлу был добавлен дополнительный символ новой строки (C ++11 §2.2 / 1).

Answer 2

Требование, чтобы каждый исходный файл заканчивался неэкранированной новой строкой, было удалено в C ++ 11.Теперь спецификация гласит:

Исходный файл, который не является пустым и который не заканчивается символом новой строки или который заканчивается символом новой строки, которому непосредственно предшествует символ обратной косой черты перед любым таким объединением, должен обрабатываться так, как если бы к файлу был добавлен дополнительный символ новой строки (C ++11 §2.2 / 1).

Соответствующий компилятор больше не должен выдавать это предупреждение (по крайней мере, не при компиляции в режиме C ++ 11, если у компилятора есть режимы для разных ревизий спецификации языка).

Answer 3

Стандарт C ++ 03 [2.1.1.2] объявляет:

...Если исходный файл, который не является пустым, не заканчивается символом новой строки или заканчивается символом новой строки непосредственно перед символом обратной косой черты перед любым таким объединением, поведение не определено.

Answer 4

Ответ для "послушного" таков: "потому что стандарт C ++ 03 гласит, что поведение программы, не заканчивающейся на символ новой строки, не определено" (перефразировано).

Ответ для любопытных находится здесь: http://gcc.gnu.org/ml/gcc/2001-07/msg01120.html.

Answer 5

Это относится не к пустой строке, а к тому, заканчивается ли последняя строка (в которой может содержаться содержимое) новой строкой.

Большинство текстовых редакторов помещают символ новой строки в конец последней строки файла, поэтому, если в последней строке его нет, существует риск того, что файл был усечен.Однако существуют веские причины, по которым вам может не понадобиться перевод строки, поэтому это всего лишь предупреждение, а не ошибка.

Answer 6

#include заменит его строку буквальным содержимым файла.Если файл не заканчивается новой строкой, строка, содержащая #include тот, кто его вставил, сольется со следующей строкой.

Answer 7

Я использую среду IDE без c версии 5.0, в моей программе на любом из языков "c ++" или "c" у меня возникла такая же проблема.Просто в конце программы т. е.последняя строка программы (после фигурных скобок функции это может быть main или любая другая функция),нажмите enter-строка №.будет увеличено на 1.затем запустите ту же программу, она будет работать без ошибок.

Answer 8

Конечно, на практике каждый компилятор добавляет новую строку после #include .К счастью.– @mxcl

не конкретный C / C ++, а диалект C:при использовании GL_ARB_shading_language_include расширение компилятор glsl в OS X предупреждает вас НЕТ о пропущенной новой строке.Таким образом, вы можете написать MyHeader.h файл с защитным заголовком, который заканчивается на #endif // __MY_HEADER_H__ а ты будет потеряйте связь после того, как #include "MyHeader.h" наверняка.

Answer 9

Потому что поведение отличается в разных версиях C / C ++, если файл не заканчивается новой строкой.Особенно неприятны старые версии C ++, fx в C ++ 03, как указано в стандарте (этапы перевода):

Если исходный файл, который не является пустым, не заканчивается символом новой строки или заканчивается символом новой строки, которому непосредственно предшествует символ обратной косой черты , поведение не определено.

Неопределенное поведение - это плохо:соответствующий стандарту компилятор мог бы сделать здесь более или менее то, что он хочет (вставить вредоносный код или что-то еще) - явно причина для предупреждения.

Хотя в C ++ 11 ситуация лучше, рекомендуется избегать ситуаций, когда поведение не определено в более ранних версиях.Спецификация C ++ 03 хуже, чем C99, которая прямо запрещает такие файлы (затем определяется поведение).

Answer 10

Это предупреждение также может указывать на то, что файл мог быть каким-то образом усечен.Это правда, что компилятор, вероятно, в любом случае выдаст ошибку компилятора - особенно если она находится в середине функции - или, возможно, ошибку компоновщика, но они могут быть более загадочными и не гарантированно возникнут.

Конечно, это предупреждение также не гарантируется, если файл обрезается сразу после перевода строки, но оно все равно может выявить некоторые случаи, которые могут быть пропущены другими ошибками, и дает более сильный намек на проблему.

Answer 11

Это не ошибка.Это просто предупреждение.

Откройте файл в редакторе, перейдите к последней строке файла и нажмите enter, чтобы добавить пустую строку в конец файла.

Хотя, помимо этого, вы должны использовать #include <iostream> вместо того, чтобы <iostream.h>.Затем положите в using std::cout; после этого.