Re: New-line fight: Comment -vs- the end of source file
Stephan Kuhagen wrote:
James Kanze wrote:
In practice, I cannot see a system where it is possible to
generate a text file which doesn't end in a newline (it's not
possible on most systems---Windows and Unix are exceptions in
this regard),
;-) "Exceptions"...? What percentage of the world wide
installed computers are NOT one of these...?
Probably somewhere around 90%---most of the computers in my home
or my car do NOT run either Windows nor Unix.
But that's not the issue. Windows and Unix are, roughly
speaking, two operatings systems (although there are at least
two code bases for Windows, and God knows how many incompatible
variants of Unix). Globally, there have been hundreds, if not
thousands, of different OS's. Most haven't had quite the
commercial success of Windows, or even of Unix, but they do
exist (or have existed).
And it IS possible on most system. E.g. I'm using emacs on
every system, and I can of course generate my files without
newline at the end.
On an IBM mainframe? The last time I looked there, emacs wasn't
available. And text files were stored as variable length
records, with no new-line characters anywhere. The compiler,
and just about every other program you can think of, treated the
end of each record as a line-end. And since you can't write
data outside a record, and every record has an end...
From what I've seen outside the Unix/Windows world, this would
seem to be the usual situation. It's impossible to write a text
file that has a "partial" line.
But the default in the c++-Mode of emacs is to append a
newline automatically. And I think, it should be default on
all programming editors. OTOH a editor should save what I have
typed, and not what the editor likes better. So if I omit the
newline, it may ask, if I'm sure, but it should not modify my
files without notice.
The question is what you are editing. If the text is a sequence
of lines (and a lot of text is), then the editor should output
it as a sequence of lines. Whatever that means to the operating
system. Under Windows, I do NOT type a CRLF, for example. For
that matter, under Unix, I don't type a control-J, either. In
both cases, I use the Enter key to tell the editor that I want
the following text to be on a new line. In no case do I
explicitly enter a new-line character (or whatever its
representation is on the system I'm working on); I tell the
editor that this text is part of a different line than the
preceding, and it does whatever is necessary. The text is a
sequence of lines, which is what the editor should store. And
by definition, when a C++ compiler reads it, it appends a
new-line character to the end of each line.
When it comes down to it, perhaps the problem is that Microsoft
hasn't made clear the definition of a sequence of lines in a
text file, and that different groups at Microsoft disagree as to
whether the CRLF is a terminator (and thus must be at the end of
every file which is a sequence of lines, and it is the
responsibility of whoever is writing the file to put it there),
or a separator (in which case, its presence at the end of a text
file means that the file ends with an empty line).
Note that this has consequences for the C++ runtime as well;
when reading a file in text mode, every line ends in a '\n', and
it is the responsibility of the library to do whatever is
necessary for this to be the case. In particular, IF the
definition for Windows is that CRLF is a separator, and not a
terminator, partial lines aren't possible, and the library must
automatically add a '\n' after it has read the last character in
the file, in addition to converting the CRLF sequence to '\n'.
especially by those that are starting on C++. And, I can't
imagine any compiler not doing the right thing in this
situation anyway.
You mean, emit a warning or an error?
I'm responsible for a build system here at our company, and I
would like it to be an error, because otherwise you can't get
some programmers to add a newline, so I always have to deal
with those annoying newline-warnings myself.
With the difference that this problem is related (and more or
less imposed) by external issues, and is normally handled by the
editor. (I wanted to see what g++ did in such cases---I
couldn't generate such a file with the editors I had at hand,
and had to write a C++ program to generate the code.)
g++ generates a warning by default but with -Werror or
-pedantic-errors it generates an error.
But of course, g++ comes from the Unix world, and applies the
Unix definition, where LF is a terminator (and not a separator).
But so far, in this thread I have not found any good reason
for this rule, except convenience. The only reason I can
think of would be source, that is piped into a compiler
through a buffered named pipe, that may block if no eof is
found. But are there any real reason? The file system
mentioned seem a little outdated as a reason for me.
I think so to. Another reason may have to do with the extra
work involved in defining what happens when the last character
is an escaped new-line. Today, there are only two cases: a
non-escaped new-line, and undefined behavior.
A third reason why it doesn't change is inertia. Whatever the
original reasons, they have been lost in time, but it works, so
no one bothers to change it.
In the meantime, it might not be a bad idea if Microsoft got the
guys who write the editor and the guys who write the compiler
together, to agree on their definition of a line. Since I find
it hard to imagine that they consider the editor in Visual
Studios a word processor or such, and not a program editor,
which is line oriented.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]