Domanda

Qual è il motivo per il seguente avviso in alcuni compilatori C++?

No newline at end of file

Perché dovrei avere una riga vuota alla fine di una sorgente, file di intestazione?

È stato utile?

Soluzione

Pensiamo ad alcuni dei problemi che possono verificarsi se non c'è un ritorno a capo.Secondo lo standard ANSI il #include di un file all'inizio inserisce il file esattamente come per la parte anteriore del file e di non inserire la nuova riga dopo la #include <foo.h> dopo il contenuto del file.Quindi, se si include un file senza carattere di nuova riga alla fine del parser sarà considerato come se l'ultima riga di foo.h sulla stessa linea come la prima linea di foo.cpp.Che cosa succede se l'ultima riga di pippo.h era un commento senza una nuova linea?Ora, la prima linea di foo.cpp è commentato.Questi sono solo un paio di esempi dei tipi di problemi che possono insinuarsi.


Volevo solo punto tutte le parti interessate, James risposta qui sotto.Mentre il precedente risposta è ancora corretto per il C, il nuovo standard C++ (C++11) è stato modificato in modo che questo avviso non dovrebbero più essere rilasciato se l'utilizzo di C++ e di un compilatore conforme al C++11.

Da standard C++11 via Giacomo' post:

Un file di origine che non è vuoto e che non si esaurisce in una nuova linea di carattere, o che finisca in una nuova linea di carattere immediatamente preceduto da un carattere barra rovesciata, prima che tale splicing avviene, devono essere trattati come se un ulteriore carattere nuova riga sono stati aggiunti al file (C++11 §2.2/1).

Altri suggerimenti

Il requisito che ogni file sorgente fine con un non di escape newline è stato rimosso in C++11.La specifica si legge:

Un file di origine che non è vuoto e che non si esaurisce in una nuova linea di carattere, o che finisca in una nuova linea di carattere immediatamente preceduto da un carattere barra rovesciata, prima che tale splicing avviene, devono essere trattati come se un ulteriore carattere nuova riga sono stati aggiunti al file (C++11 §2.2/1).

Conforme compilatore non dovrebbe più problema di questo avviso (almeno non durante la compilazione in C++11 modalità, se il compilatore ha modalità diverse revisioni della specifica del linguaggio).

C++03 Standard [2.1.1.2] dichiara:

...Se un file di origine che non è vuoto, non si esaurisce in una nuova linea di carattere, o finisce in un carattere nuova riga immediatamente preceduto da un carattere barra rovesciata, prima che tale splicing avviene, il comportamento è indefinito.

La risposta per il "sottomesso" è "perché il C++03 Standard dice che il comportamento di un programma non termina in newline è definito" (parafrasato).

La risposta per i curiosi è qui: http://gcc.gnu.org/ml/gcc/2001-07/msg01120.html.

Non è facendo riferimento a una riga vuota, ma se l'ultima riga (che può avere un contenuto in esso) è terminato con un "a capo".

La maggior parte degli editor di testo inserire una nuova riga alla fine dell'ultima riga di un file, quindi se l'ultima riga non si dispone di uno, c'è il rischio che il file è stato troncato.Tuttavia, ci sono validi motivi per cui non è necessario che il capo è solo un avviso, non un errore.

#include andrà a sostituire la linea con il letterale contenuto del file.Se il file non termina con un carattere di nuova riga, la riga contenente il #include che tirato in unione con la riga successiva.

Sto usando c-IDE gratuito della versione 5.0,nel mio progrm di 'c++' o 'c' la lingua mi è stato sempre stesso problema.Solo alla fine del programma cioèultima riga del programma(dopo le parentesi graffe della funzione può essere principale o di qualsiasi altra funzione),premere invio-linea n.viene incrementato di 1.quindi eseguire lo stesso programma,verrà eseguito senza errori.

Naturalmente, in pratica ogni compilatore aggiunge una nuova riga dopo la #include.Per fortuna.– @mxcl

non specifico C/C++, ma un C dialetto:quando si utilizza il GL_ARB_shading_language_include estensione per il glsl compilatore su OS X avvisa NON manca il carattere di nuova riga.Così si può scrivere MyHeader.h file con un colpo di testa di guardia che si conclude con #endif // __MY_HEADER_H__ e si sarà perdere la linea, dopo la #include "MyHeader.h" di sicuro.

Perché il comportamento varia tra C/C++ versioni se il file non si esaurisce con la nuova linea.Particolarmente sgradevole è più vecchio C++versioni fx in C++ 03 lo standard dice (traduzione fasi):

Se un file di origine che non è vuoto, non si esaurisce in una nuova riga carattere, o finisce in un carattere nuova riga immediatamente preceduto da un carattere barra rovesciata, il comportamento è indefinito.

Un comportamento indefinito è male:un conforme agli standard del compilatore potrebbe fare più o meno ciò che si vuole qui (inserire malicous codice o quello che è) - chiaramente un motivo di attenzione.

Mentre la situazione è migliore in C++11 è una buona idea per evitare situazioni in cui il comportamento è indefinito nelle versioni precedenti.Il C++03 specifica è peggio di C99 vere e proprie vieta tale tipo di file (il comportamento è quindi definito).

Questo avviso potrebbe aiutare ad indicare che il file potrebbe essere stato troncato in qualche modo.È vero che il compilatore probabilmente gettare un errore del compilatore, comunque, soprattutto se è nel mezzo di una funzione - o forse un errore del linker, ma questi potrebbero essere più criptico, e non sono garantiti per verificarsi.

Naturalmente il presente avviso non è garantita se il file viene troncato subito dopo un "a capo", ma si potrebbe ancora prendere alcuni casi che altri errori che potrebbe perdere, e dà un forte accenno al problema.

Non è un errore.E ' solo un avvertimento.

Aprire il file in un editor, vai all'ultima riga del file, e premere invio per aggiungere una riga vuota alla fine del file.

Però, oltre a questo, si dovrebbe essere utilizzando #include <iostream> invece di <iostream.h>.Poi mettere in una using std::cout; dopo di esso.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top