"Nee newline aan die einde van lêer" samesteller waarskuwing

Question

Wat is die rede vir die volgende waarskuwing in 'n paar C ++ opstellers?

  

Geen newline aan die einde van lêer

Hoekom moet ek 'n leë lyn aan die einde van 'n bron / header lêer?

Answer 1

Dink aan 'n paar van die probleme wat kan voorkom indien daar geen newline. Volgens die ANSI standaard die #include van 'n lêer aan die begin voeg die lêer presies soos dit is aan die voorkant van die lêer en nie voeg die nuwe lyn na die #include <foo.h> na die inhoud van die lêer. So as jy 'n lêer met geen newline aan die einde van die parser dit sal gesien word asof die laaste linie van foo.h is op dieselfde lyn as die eerste lyn van foo.cpp sluit. Wat gebeur as die laaste linie van foo.h was 'n opmerking sonder 'n nuwe lyn? Nou is die eerste reël van foo.cpp is kommentaar gelewer het. Dit is net 'n paar voorbeelde van die tipes probleme wat kan bekruip.

---

Wou net om enige belangstellendes om James 'n antwoord hieronder wys. Terwyl die bogenoemde antwoord is nog korrek vir C, het die nuwe C ++ standaard (C ++ 11) is verander sodat hierdie waarskuwing nie meer moet uitgereik word indien die gebruik van C ++ en 'n samesteller wat voldoen aan C ++ 11.

Van C ++ 11 standaard via James 'post:

  

'n bron lêer wat nie leeg is nie en dat dit nie die einde in 'n nuwe lyn karakter, of wat eindig in 'n nuwe lyn karakter onmiddellik voorafgegaan word deur 'n back slash voor so 'n splitsing plaasvind, sal asof 'n verwerk addisionele nuwe-lyn karakter is aangeheg aan die lêer (C ++ 11 §2.2 / 1).

Answer 2

Die vereiste dat elke bron lêer eindig met 'n nie-ontsnap newline verwyder in C ++ 11. Die spesifikasie lees nou:

  

'n bron lêer wat nie leeg is nie en dat dit nie die einde in 'n nuwe lyn karakter, of wat eindig in 'n nuwe lyn karakter onmiddellik voorafgegaan word deur 'n back slash voor so 'n splitsing plaasvind, sal asof 'n verwerk addisionele nuwe-lyn karakter is aangeheg aan die lêer (C ++ 11 §2.2 / 1).

'n voldoen samesteller moet nie langer hierdie waarskuwing uit te reik (ten minste nie by die opstel van in C ++ 11 af, as die opsteller het modes vir verskillende weergawes van die taalspesifikasie).

Answer 3

C ++ 03 Standard [2.1.1.2] verklaar:

  

... As 'n bron lêer wat nie leeg is nie eindig nie in 'n nuwe lyn karakter, of eindig in 'n nuwe lyn karakter   onmiddellik voorafgegaan word deur 'n back slash voor so 'n splitsing plaasvind, die gedrag is ongedefinieerd.

Answer 4

Die antwoord vir die "gehoorsaam" is "omdat die C ++ 03 Standard sê die gedrag van 'n program nie eindig in newline ongedefinieerd" (geparafraseer).

Die antwoord vir die nuuskierige is hier: http: // gcc .gnu.org / ml / gcc / 2001-07 / msg01120.html .

Answer 5

Dit verwys nie na 'n leë lyn, dis of die laaste reël (wat inhoud in dit kan hê) beëindig met 'n newline.

Die meeste teksredigeerders sal 'n newline sit aan die einde van die laaste lyn van 'n lêer, so as die laaste linie nie een het nie, is daar 'n risiko dat die lêer is afgekap. Daar is egter geldige redes waarom jy nie wil dalk die newline so dit is net 'n waarskuwing, nie 'n fout.

Answer 6

#include sal sy lyn te vervang met die letterlike inhoud van die lêer. As die lêer eindig nie met 'n newline, sal die lyn met die #include dat dit in getrek saam te smelt met die volgende lyn.

Answer 7

Ek gebruik c-vrye IDE weergawe 5.0, in my progrm óf van 'c ++ "of" c "taal ek besig was om dieselfde problem.Just aan die einde van die program ie laaste linie van die program (na draadjies van funksie kan hoof- of enige funksie wees), druk enter LINE no. sal verhoog word deur 1.then voer dieselfde program, sal dit uitgevoer word sonder fout.

Answer 8

  

Natuurlik in die praktyk elke samesteller voeg 'n nuwe lyn na die # include. Gelukkig. - @mxcl

nie spesifieke C / C ++ maar 'n C dialek: wanneer die gebruik van die GL_ARB_shading_language_include uitbreiding die GLSL samesteller op OS X waarsku jy nie oor 'n vermiste newline. Sodat jy kan 'n MyHeader.h lêer met 'n kop wag wat eindig met #endif // __MY_HEADER_H__ skryf en jy sal verloor die lyn na die #include "MyHeader.h" vir seker.

Answer 9

As gevolg van die gedrag verskil tussen C / C ++ weergawes as lêer eindig nie met 'n nuwe lyn. Veral nare ouer C ++ - weergawes, fx in C ++ 03 die standaard sê (vertaling fases):

  

As 'n bron lêer wat nie leeg is nie eindig nie in 'n nuwe-lyn   karakter, of eindig in 'n nuwe lyn karakter onmiddellik voorafgegaan word deur 'n   agteroorskuinsstreep karakter, die gedrag is ongedefinieerd.

Undefined gedrag is sleg. 'N standaard konformerende samesteller kan min of meer doen wat hulle wil hier (voeg malicous kode of wat ook al) - duidelik 'n rede vir waarskuwing

Terwyl die situasie is beter in C ++ 11 dit is 'n goeie idee om situasies waar die gedrag is ongedefinieerd in vorige weergawes te vermy. Die C ++ 03 spesifikasie is erger as C99 wat volslae sulke lêers verbied (gedrag word dan gedefinieer).

Answer 10

Hierdie waarskuwing kan ook help om aan te dui dat 'n lêer is een of ander manier kon kapt. Dit is waar dat die samesteller waarskynlik 'n samesteller fout sal gooi in elk geval - veral as dit in die middel van 'n funksie -. Of miskien 'n linker fout, maar dit kan meer kriptiese wees, en is nie gewaarborg om plaas te vind

Natuurlik hierdie waarskuwing ook nie gewaarborg as die lêer onmiddellik is afgesny nadat 'n newline, maar dit kon nog vang sommige gevalle dat ander foute kan mis, en gee 'n sterker wenk om die probleem.

Answer 11

Dit is nie 'n fout. Dis net 'n waarskuwing.

Maak die lêer in 'n redakteur, gaan na die laaste reël van die lêer, en druk enter om 'n leë lyn toe te voeg tot die einde van die lêer.

Hoewel, behalwe dat jy moet wees met behulp van #include <iostream> in plaas van <iostream.h>. sit dan in 'n using std::cout; nadat dit.