mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > Software

Reply
 
Thread Tools
Old 2023-01-28, 23:59   #980
storm5510
Random Account
 
storm5510's Avatar
 
Aug 2009
Not U. + S.A.

1001111000102 Posts
Default

Quote:
Originally Posted by rogue View Post
...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.
storm5510 is offline   Reply With Quote
Old 2023-01-29, 22:32   #981
Mark Rose
 
Mark Rose's Avatar
 
"/X\(‘-‘)/X\"
Jan 2013

1100000101112 Posts
Default

Quote:
Originally Posted by storm5510 View Post
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/
Mark Rose is offline   Reply With Quote
Old 2023-02-01, 05:51   #982
LaurV
Romulan Interpreter
 
LaurV's Avatar
 
"name field"
Jun 2011
Thailand

1027910 Posts
Default

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
LaurV is offline   Reply With Quote
Old 2023-02-01, 13:18   #983
Andrew Usher
 
Dec 2022

3328 Posts
Default

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).
Andrew Usher is offline   Reply With Quote
Old 2023-02-02, 00:11   #984
storm5510
Random Account
 
storm5510's Avatar
 
Aug 2009
Not U. + S.A.

2×5×11×23 Posts
Default

Quote:
Originally Posted by Andrew Usher View Post
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.
storm5510 is offline   Reply With Quote
Old 2023-02-02, 13:49   #985
Andrew Usher
 
Dec 2022

21810 Posts
Default

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.
Andrew Usher is offline   Reply With Quote
Reply

Thread Tools


All times are UTC. The time now is 00:26.


Fri Feb 3 00:26:16 UTC 2023 up 168 days, 21:54, 1 user, load averages: 0.89, 0.92, 0.91

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2023, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.

≠ ± ∓ ÷ × · − √ ‰ ⊗ ⊕ ⊖ ⊘ ⊙ ≤ ≥ ≦ ≧ ≨ ≩ ≺ ≻ ≼ ≽ ⊏ ⊐ ⊑ ⊒ ² ³ °
∠ ∟ ° ≅ ~ ‖ ⟂ ⫛
≡ ≜ ≈ ∝ ∞ ≪ ≫ ⌊⌋ ⌈⌉ ∘ ∏ ∐ ∑ ∧ ∨ ∩ ∪ ⨀ ⊕ ⊗ 𝖕 𝖖 𝖗 ⊲ ⊳
∅ ∖ ∁ ↦ ↣ ∩ ∪ ⊆ ⊂ ⊄ ⊊ ⊇ ⊃ ⊅ ⊋ ⊖ ∈ ∉ ∋ ∌ ℕ ℤ ℚ ℝ ℂ ℵ ℶ ℷ ℸ 𝓟
¬ ∨ ∧ ⊕ → ← ⇒ ⇐ ⇔ ∀ ∃ ∄ ∴ ∵ ⊤ ⊥ ⊢ ⊨ ⫤ ⊣ … ⋯ ⋮ ⋰ ⋱
∫ ∬ ∭ ∮ ∯ ∰ ∇ ∆ δ ∂ ℱ ℒ ℓ
𝛢𝛼 𝛣𝛽 𝛤𝛾 𝛥𝛿 𝛦𝜀𝜖 𝛧𝜁 𝛨𝜂 𝛩𝜃𝜗 𝛪𝜄 𝛫𝜅 𝛬𝜆 𝛭𝜇 𝛮𝜈 𝛯𝜉 𝛰𝜊 𝛱𝜋 𝛲𝜌 𝛴𝜎𝜍 𝛵𝜏 𝛶𝜐 𝛷𝜙𝜑 𝛸𝜒 𝛹𝜓 𝛺𝜔