mtsieve - Page 90

storm5510 · 2023-01-28, 23:59

Quote:

Originally Posted by rogue

...The difference between \n and \r doesn't make any sense. The code is GPU agnostic. But if it works for you, then who am I to complain.

I remember \n from trade school. New line. \r must be more recent. As long as it does its job and you have no suspicions about it working properly, then no problem here.

Mark Rose · 2023-01-29, 22:32

Quote:

Originally Posted by storm5510

I remember \n from trade school. New line. \r must be more recent. As long as it does its job and you have no suspicions about it working properly, then no problem here.

Unix traditionally used the line feed character (ASCII 10 or 0A) for a new line, commonly represented as \n.

Old Mac, before Mac OS X (which is Unix under the hood), used the carriage return character (13 or 0D), \r.

CP/M used both, \r\n. In many ways MS DOS was modelled after CP/M, including the use of both characters for a new line. That has continued on to modern Windows.

Most programming languages discard white space. Most editors are smart enough to work with the existing encoding of a text file.

https://blog.codinghorror.com/the-great-newline-schism/

LaurV · 2023-02-01, 05:51

Real programmers (TM) use \r or CR (carriage return) or ascii code 13 (hex 0x0D) for bringing the cursor at the beginning of the line, without advancing to the new line. This is very useful when you have "counting counters" or other running numbers or info on screen and you want that info to stay on the same line without changing the rest of the screen.
Same way, \n or LF (line feed) or ascii code 10 (hex 0x0A) is used to advance the line without bringing the cursor to the beginning of the line. Like moving the cursor down one row. You have also codes to move the cursor up, or left, right. On former tty (text) monitors (like VT100, etc) you would have to move the cursor here or there to write drop down menus, rewrite the screen under those, when the menu is closed, etc. There is also a FF character (form feed, page skip, you can see all these in an ascii table) which is dated from before terminals, when all the interface was on printer, and the printer would have to go to the next page. In "modern times" they got different uses but a "clever" terminal (like TeraTerm, etc., but also partially for less clever terminals like windows' HT or the command prompt) may have specific settings how these characters (and their combinations are treated). Some "less clever" systems/programs will make no difference and treat all of them like being both CR+LF, i.e. the cursor comes to the beginning of the next like - this is stupid and makes your screen behave like an old typewriter where you had a crowbar to push to return the carriage and advance a line in the same time, Norman style... There you can not (easily) make a running counter on screen, and generally your "grades of liberty" when you design the "text interface" of your program are much restricted.

Andrew Usher · 2023-02-01, 13:18

It would be nice to have the characters always work in that 'logical' way, but that can't be assumed anymore. In that case a newline would consist of both characters (in either order) and there DOS/Windows have it right, and CR+LF was not invented by CP/M but goes back to the ASCII standard, which in turn was based on actual typewriter/teletype use.

Unix is gratuitously incompatible here, and for the sake of saving one byte per line, which seems absurd today (it also makes the tricks you suggest impossible, as does the standard C library, based on Unix conventions).

storm5510 · 2023-02-02, 00:11

Quote:

Originally Posted by Andrew Usher

It would be nice to have the characters always work in that 'logical' way, but that can't be assumed anymore. In that case a newline would consist of both characters (in either order) and there DOS/Windows have it right, and CR+LF was not invented by CP/M but goes back to the ASCII standard, which in turn was based on actual typewriter/teletype use.

Unix is gratuitously incompatible here, and for the sake of saving one byte per line, which seems absurd today (it also makes the tricks you suggest impossible, as does the standard C library, based on Unix conventions).

I would think that, regardless of the programming language, the actual binary values of each would not change. From my days of tinkering with hex editors, I recognized them as 0A 0D.

Andrew Usher · 2023-02-02, 13:49

Actually, 0D 0A in DOS/Windows format (the other order won't generally work), but in a Unix-format text file, it really is just 0A. In any case, the C standard output converts all newlines written to it explicitly or implicitly into both functions, regardless of the system implementation, and the same is true of files opened in text mode (which are treated the same - another Unixism).

There is a way of doing the 'running counter' trick in DOS (don't know if it works the same in modern Windows) using non-standard functions, and it can be done in Unix also, but differently - there is no portable way of moving the cursor using ASCII characters, though there was supposed to be.

2023-02-01, 05:51	#982
LaurV Romulan Interpreter "name field" Jun 2011 Thailand 10279₁₀ Posts	Real programmers (TM) use \r or CR (carriage return) or ascii code 13 (hex 0x0D) for bringing the cursor at the beginning of the line, without advancing to the new line. This is very useful when you have "counting counters" or other running numbers or info on screen and you want that info to stay on the same line without changing the rest of the screen. Same way, \n or LF (line feed) or ascii code 10 (hex 0x0A) is used to advance the line without bringing the cursor to the beginning of the line. Like moving the cursor down one row. You have also codes to move the cursor up, or left, right. On former tty (text) monitors (like VT100, etc) you would have to move the cursor here or there to write drop down menus, rewrite the screen under those, when the menu is closed, etc. There is also a FF character (form feed, page skip, you can see all these in an ascii table) which is dated from before terminals, when all the interface was on printer, and the printer would have to go to the next page. In "modern times" they got different uses but a "clever" terminal (like TeraTerm, etc., but also partially for less clever terminals like windows' HT or the command prompt) may have specific settings how these characters (and their combinations are treated). Some "less clever" systems/programs will make no difference and treat all of them like being both CR+LF, i.e. the cursor comes to the beginning of the next like - this is stupid and makes your screen behave like an old typewriter where you had a crowbar to push to return the carriage and advance a line in the same time, Norman style... There you can not (easily) make a running counter on screen, and generally your "grades of liberty" when you design the "text interface" of your program are much restricted. Last fiddled with by LaurV on 2023-02-01 at 05:52

2023-02-01, 13:18	#983
Andrew Usher Dec 2022 332₈ Posts	It would be nice to have the characters always work in that 'logical' way, but that can't be assumed anymore. In that case a newline would consist of both characters (in either order) and there DOS/Windows have it right, and CR+LF was not invented by CP/M but goes back to the ASCII standard, which in turn was based on actual typewriter/teletype use. Unix is gratuitously incompatible here, and for the sake of saving one byte per line, which seems absurd today (it also makes the tricks you suggest impossible, as does the standard C library, based on Unix conventions).

2023-02-02, 13:49	#985
Andrew Usher Dec 2022 218₁₀ Posts	Actually, 0D 0A in DOS/Windows format (the other order won't generally work), but in a Unix-format text file, it really is just 0A. In any case, the C standard output converts all newlines written to it explicitly or implicitly into both functions, regardless of the system implementation, and the same is true of files opened in text mode (which are treated the same - another Unixism). There is a way of doing the 'running counter' trick in DOS (don't know if it works the same in modern Windows) using non-standard functions, and it can be done in Unix also, but differently - there is no portable way of moving the cursor using ASCII characters, though there was supposed to be.