Line Feed and Carriage Return

Question

Recently I was working with some strings, text input, things like that and I realized I got little confused about 2 characters - LF(10) and CR(13). Every time I needed to start new line I used std::endl for c++ string and \n which is LF for c-strings. However I'm now using one library which on return key press sends me not LF but CR key code. I read on wikipedia that usage is as follows:

CR+LF: Microsoft Windows, DEC TOPS-10, RT-11 and most other early non-Unix and non-IBM OSes, CP/M, MP/M, DOS (MS-DOS, PC-DOS, etc.), Atari TOS, OS/2, Symbian OS, Palm OS
LF+CR: Acorn BBC spooled text output.
CR:    Commodore 8-bit machines, Acorn BBC, TRS-80, Apple II family, Mac OS up to version 9 and OS-9
LF:    Multics, Unix and Unix-like systems (GNU/Linux, AIX, Xenix, Mac OS X, FreeBSD, etc.), BeOS, Amiga, RISC OS, and others.
RS:    QNX pre-POSIX implementation.

But I never really noticed need for CR on windows, everything gets printed anyway at right location. CR, again according to wikipedia, was used in times of type writers for returning that writing head to begining of line, and then LF for scrolling one line bellow.

My question is if it's really necessary these days to use CR and why. What systems could possibly fail to output text correctly if only LF is used? Does printers still require CR and if so, does OS automaticly interpret LF as both new line and return to start of line or CR must be still hardcoded in data that I sent for printing?

Answer 1

Inside your C and C++ programs all you need (at least, when dealing just with the standard library) is \n, which, when sent to any C/C++ stream opened in text mode (i.e. when you don't specify b into the fopen and ios::bin for C++ streams), is automatically translated to the line terminator of the current platform. That's why on Windows you can just write \n to any stream and it becomes "magically" CRLF into the file/on the console.

The whole binary/text mode thing exist for this purpose: when you are writing a text file it's useful to have this translation (this way inside your strings you can just have \n as line terminator without worrying about the specific platform line terminator), but when you're writing a binary file \n is just a byte like the others and should not be translated, otherwise you get corrupted data.

*NIX systems that use just LF (which is \n) don't actually do any translation, but it's still good to specify correctly binary/text mode for portability/clarity purposes.

Using always endl in C++ is a common mistake, \n is enough to get the translation to the platform-specific line terminator.

What endl does more than \n is to flush the stream buffer, which can be useful in some limited circumstances (e.g. outputting something on a console before a long operation), but in general just slows down the IO (on consoles it's usually not noticeable, but on files it is). I usually just use \n and add a std::flush when a flush is actually needed.

---

This for what concerns the standard library; when dealing with other libraries YMMV and you should check their documentation to see if they follow the standard C convention or they require strings to contain the platform-specific line terminator.