No new line at end of file? What does this mean?

BajaNick · 01-24-2005, 08:31 PM

I am messing around with cpp and I typed up this simple code:
// first C++ program

#include <iostream.h>

int main ()
{
cout <<" Hello World!";
return 0;
}

Then I do cpp test.cpp
and lots of stuff flies by on the screen and I get the error: test.cpp:9:2: warning: no newline at end of file.
should I be using something else other than cpp progname.cpp?
Is there a way to do away with this errror?
I am using cpp version 3.3.4
Thanks.

johnMG · 01-24-2005, 08:45 PM

> and I get the error: test.cpp:9:2: warning: no newline at end of file.

That's not an error. It's just a warning.

Open the file in an editor, go to the last line of the file, and hit enter to add a blank line to the end of the file. :)

Though, besides that, you should be using #include <iostream> instead of <iostream.h>. Then put in a "using std::cout;" after it.

BajaNick · 01-24-2005, 08:57 PM

That did it, Thanks alot.

I think some of the online tutorials might be kinda outdated.

reddazz · 01-24-2005, 10:04 PM

Yeah, I ended up buying a c++ book coz most of the stuff on the web is outdated.

shadypalm88 · 01-24-2005, 11:06 PM

Just out of curiosity, what's the point of having the extra newline at the end of the file? gcc on OS X doesn't give this warning.

jlliagre · 01-25-2005, 01:58 AM

It's not an extra new-line, each line should be terminated by an "end of line" tag, and this is \n under unix.
On MacOS, this used to be \r, perhaps the reason why gcc is more tolerant on newer releases of this O/S.

phoenix7 · 02-07-2005, 03:23 PM

do you know real reason of that?

johnMG · 02-07-2005, 03:37 PM

There's probably still some ancient compilers out there (maybe even very old versions of GCC?) that want each line to end with a newline or else they crash. My guess is that GCC is just trying to help you make your code compatible with these dino's.

itsme86 · 02-07-2005, 06:30 PM

Actually, gcc warns about it because it has to according to the standard. Check out this link for a brief description: http://gcc.gnu.org/ml/gcc/2003-11/msg01568.html

If you have a compiler that doesn't warn you about the lack of a newline character then that compiler doesn't meet the standards. Burn the disc it came on and get a real compiler.

Vasileios Keleris · 05-04-2013, 07:20 PM

Great!

cr0ck3t · 05-11-2014, 11:23 PM

I developed some software which had to receive a configuration file via a socket connection... but the software which generated the file did not include a newline at the end - no big deal, right? They had accounted for this, and to indicate 'no more config entries' the last line was "99=0"...

The non-newline EOF was not documented, so I happily tried the following:

Code:

Socket socket = new Socket(hostName, portNumber);
BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(socket.getInputStream()));

String input;
while(!(input = bufferedReader.readLine()).equals("99=0")) {
	// ... process the input
}

... which would block while waiting for the elusive newline until the socket connection finally timed out - which took way too long - so I called their technical support and they were at a loss as well... I finally fixed it by swapping out the above while loop with following code:

Code:

InputStream input = socket.getInputStream();
String response = "";
byte NEWLINE = (byte) '\n';
boolean getMoreData = true;

while (getMoreData) {
	String temp = "";
	byte subTemp = (byte)0;
	while(subTemp != NEWLINE)
		subTemp = (byte)input.read();
	temp += new String(new byte[]{subTemp}, "UTF-8");
	if(("99=0".equals(temp))){
		getMoreData = false;
		temp += new String(new byte[]{NEWLINE}, "UTF-8");
	}
	response += temp;
}

//break out the parts of the response
String[] split = response.split("\n");

for(String inputLine:split){
	// ... process the input
}

ejspeiro · 05-19-2014, 11:11 AM

I would call this one as solved

sundialsvcs · 05-19-2014, 08:39 PM

Come with me, back to the days of Yore, back to the days which I remember!

(and nay, I do not apologize for those memories ... "sorry you missed it")

In those grand old days of ASCII, there were two characters which controlled the teletype(!) and DECWriter terminals of those days: CR = Carriage Return (Chr(12)) and LF = Line Feed (Chr(10)). Technically, both characters were required by the equipment. However, in actual practice, sometimes it was one, sometimes it was the other, and sometimes it was both (in either order).

And, as time marched on (and computer programmers, as usual, could never quite decide ...) all four possibilities wound up sticking around for the next X decades.

Sorry 'bout that.