C++: Is there a standard definition for end-of-line in a multi-line string constant?

Question

If I have a multi-line string C++11 string constant such as

R\"\"\"line 1
line 2
line3\"\"\"

Is it defined what character(s) the line termi

Answer 1

^{Note: the question has changed substantially since the answers were posted. Only half of it remains, namely the pure C++ aspect. The network focus in this answer addresses the original question's “sending a multi-line string to a server with well-defined end-of-line requirements”. I do not chase question evolution in general.}

Internally in the program, the C++ standard for newline is \n. This is used also for newline in a raw literal. There is no special convention for raw literals.

Usually \n maps to ASCII linefeed, which is the value 10.

I'm not sure what it maps to in EBCDIC, but you can check that if needed.

On the wire, however, it's my impression that most protocols use ASCII carriage return plus linefeed, i.e. 13 followed by 10. This is sometimes called CRLF, after the ASCII abbreviations CR for carriage return and LF for linefeed. When the C++ escapes are mapped to ASCII this is simply \r\n in C++.

You need to abide by the requirements of the protocol you're using.

For ordinary file/stream i/o the C++ standard library takes care of mapping the internal \n to whatever convention the host environment uses. This is called text mode, as opposed to binary mode where no mapping is performed.

For network i/o, which is not covered by the standard library, the application code must do this itself, either directly or via some library functions.

---

There is an active issue about this, core language defect report #1655 “Line endings in raw string literals”, submitted by Mike Miller 2013-04-26, where he asks,

” is it intended that, for example, a CRLF in the source of a raw string literal is to be represented as a newline character or as the original characters?

Since line ending values differ depending on the encoding of the original file, and considering that in some file systems there is not an encoding of line endings, but instead lines as records, it's clear that the intention is not to represent the file contents as-is – since that's impossible to do in all cases. But as far as I can see this DR is not yet resolved.