I've came to think of it, why are many linux apps so pointy about files without a new line at EOF? Is there a reson for that? If so what, I see no need for a new line at EOF...
Posted on 2003-08-09 13:07:41 by scientica
The C++ standard has the somewhat strange requirement that source files that are not empty should end with a newline (leaving it out produces undefined results, although usually it doesn't matter) .. Don't know if that's the reason but could be.

Thomas
Posted on 2003-08-09 13:31:29 by Thomas

source files that are not empty should end with a newline

Hmm, so null files aren't allowed in Standard C++?
Well, this would mean that not just *nix/Linux specific, but I haven't heard windows (or any windows app excet for UnixUtils - a bunch of ported *unix/linux tools, how can one live with out commands like less, ls, diff?) complain about it. or does windows tools that care about it add the new line silently?
Posted on 2003-08-10 05:05:21 by scientica
I don't see the point either. My only guess is that the old C compiler programmers were too lazy to implement a check for EOF.
Posted on 2003-08-10 09:53:26 by iblis
actually the biggest reason for LF-at-end in C programs has to do with header files, and the way the preprocessor works... consider a header file with "include guards", ending with



#endif


- notice the lack of LF!
Now, this header file is used like this...



#include "foo.h"
int myvar;


Guess what will happen?



#endifint myvar;
Posted on 2003-08-10 09:55:42 by f0dder
Ok now I see, but IMO, it should be the preprocessors thing to make sure that wouldn't happen...
Posted on 2003-08-10 13:16:37 by scientica
I think the problem stems from the fact that cin or read block (ie wait) until a next line character is entered.

The programs probably loop until read returns zero or Ctrl-D is entered.
Posted on 2003-08-19 18:03:56 by eet_1024
don't make wild guesses.
Posted on 2003-08-20 02:02:21 by f0dder

I think the problem stems from the fact that cin or read block (ie wait) until a next line character is entered.

The programs probably loop until read returns zero or Ctrl-D is entered.

if you type:
cout << "print *now*\n" << flush; // it'll print it out directly
cout << "print when ever\n"; // this may print out now, or later, better flush when you want the text out.
cout << some more text << endl;
Posted on 2003-08-20 03:15:35 by scientica
Depends on how programmers handle line-oriented input. C and a few other languages (like Perl) don't hide the newline character in line-oriented input. This means a zero-length line is the end-of-file. If the line string always has at least one character, you can delete the last character whether it's a newline or not. If the character at the end of the line isn't tested...

In line-oriented input, you also have the problem of long lines. You can either ignore the rest of the line, or chop it into parts that fit in the input buffer. In either case, you end up with lines that don't end with newlines.
Posted on 2003-08-20 22:49:08 by tenkey