portable std::getline and line terminators

[fft1976]

Hi

If I open my ifstream in text mode (default ios_base:penmode?),
std::getline may or may not eat '\r' with '\n', and << '\n' may or
may not write '\r', correct?

(I actually use boost::filesystem::ifstream, but the behavior should
be the same, as it aims to be a replacement)

What I'd like to do is to write the output in the same format the
input was in (even if it's a Unix file on Windows and vice versa).
What's a good way to achieve this? Is binary I/O the only viable
approach?

 

[Bo Persson]

Hi

If I open my ifstream in text mode (default ios_base:penmode?),
std::getline may or may not eat '\r' with '\n', and << '\n' may or
may not write '\r', correct?

(I actually use boost::filesystem::ifstream, but the behavior should
be the same, as it aims to be a replacement)

What I'd like to do is to write the output in the same format the
input was in (even if it's a Unix file on Windows and vice versa).
What's a good way to achieve this? Is binary I/O the only viable
approach?

Pretty much, yes.

The text mode I/O is supposed to read and write text files using the
conventions of the operating system you are using. If that is not what
you want...

Note that Unix and Windows are not the only known variants.


Bo Persson

 

[James Kanze]

If I open my ifstream in text mode (default
ios_base:penmode?), std::getline may or may not eat '\r'
with '\n', and << '\n' may or may not write '\r', correct?

Maybe. If you open the ifstream in text mode, you get whatever
the system defines as text mode. Under Unix, there's no
difference between text and binary modes. Under Windows, text
mode uses CRLF (instead of just LF) as a line ending (or
separator, depending on the application), and 0x1A as an end of
file character; otherwise, the two modes are basically similar.
Under some other OS's, text and binary modes may use different,
incompatible file types.

Strictly speaking, std::getline only eats a trailing '\n' (or
whatever character was given it). The modes are handled
considerably upstream of the istream, in filebuf. And end of
line could also be influenced by the imbued locale; in an 8089-1
locale, I would expect 0x85 (next line) to be mapped to '\n',
and in a UTF-8 locale, 0xE2 0x80 0xA8 (line separator).

(I actually use boost::filesystem::ifstream, but the behavior
should be the same, as it aims to be a replacement)

What I'd like to do is to write the output in the same format
the input was in (even if it's a Unix file on Windows and vice
versa). What's a good way to achieve this? Is binary I/O the
only viable approach?

Probably. Ideally, you'd have some sort of locale which could
be used for "foreign" file systems, but I don't know of any
system which actually offers this. And you'd still have the
problem of determining the conventions used on the input file,
and what to do if it is mixed.