Detecting CR/LF or LF behaviour on a particular C++ platform.

[Kevin Frey]

Hello,

Can anyone suggest a way, that does not involve writing a temporary
file, that would permit me to discover whether writing:

output_file_stream << '\n';

will write either a LF (eg. under unix) or CR/LF (eg. under Win32).

The Adobe Acrobat specification (V1.3) has a section called a
cross-reference table which must be padded to exactly 20 bytes per
line. If the operating system writes LF-only then each line has a
space appended before the LF. If the operating system writes CR/LF
then no space is appended.

Taking an entirely lateral approach, my colleague has suggested to me
that only the Win32 platform actually writes CR/LF so I should just
conditionalise the code for Win32 and *assume* all other platforms are
LF. So as a separate question - can anyone think of any other
mainstream platform that uses CR/LF. I'm under the impression this
"hangover" came from CP/M but that O/S has pretty much gone the way of
the Dodo.

Thanks

Kevin.

 

[Gianni Mariani]

Hello,

Can anyone suggest a way, that does not involve writing a temporary
file, that would permit me to discover whether writing:

output_file_stream << '\n';

will write either a LF (eg. under unix) or CR/LF (eg. under Win32).

....

Sounds like the job of a binary file.

FAQ city:

http://www.fmi.uni-konstanz.de/~kuehl/c++-faq/input-output.html#faq-15.12

 

[Dodo]

Hello,

Can anyone suggest a way, that does not involve writing a temporary
file, that would permit me to discover whether writing:

output_file_stream << '\n';

will write either a LF (eg. under unix) or CR/LF (eg. under Win32).

The Adobe Acrobat specification (V1.3) has a section called a
cross-reference table which must be padded to exactly 20 bytes per
line. If the operating system writes LF-only then each line has a
space appended before the LF. If the operating system writes CR/LF
then no space is appended.

Taking an entirely lateral approach, my colleague has suggested to me
that only the Win32 platform actually writes CR/LF so I should just
conditionalise the code for Win32 and *assume* all other platforms are
LF. So as a separate question - can anyone think of any other
mainstream platform that uses CR/LF. I'm under the impression this
"hangover" came from CP/M but that O/S has pretty much gone the way of
the Dodo.

Thanks

Kevin.

Do not assume such thing.
cr-separated = mac
crlf - windows
lf - unix systems

i have seen vlaid PDFs which have been CR separated. Kinda headache.
It broke our program which was conditioned same way as your colleague
suggested.

 

[E. Robert Tisdale]

Can anyone suggest a way, that does not involve writing a temporary
file, that would permit me to discover whether writing:

output_file_stream << '\n';

will write either a LF (eg. under unix) or CR/LF (eg. under Win32).

The Adobe Acrobat specification (V1.3) has a section called a
cross-reference table which must be padded to exactly 20 bytes per
line. If the operating system writes LF-only then each line has a
space appended before the LF. If the operating system writes CR/LF
then no space is appended.

Taking an entirely lateral approach, my colleague has suggested to me
that only the Win32 platform actually writes CR/LF so I should just
conditionalise the code for Win32 and *assume* all other platforms are
LF. So as a separate question - can anyone think of any other
mainstream platform that uses CR/LF. I'm under the impression this
"hangover" came from CP/M but that O/S has pretty much gone the way of
the Dodo.

In C++, the end of a line is always represented
by the line feed or new line character '\n'.
This is converted automatically to the End Of Line (EOL) sequence
recognized by your operation system on output
and converted from the EOL sequence to `\n' on input.

 

[Kevin Goodsell]

Hello,

Can anyone suggest a way, that does not involve writing a temporary
file, that would permit me to discover whether writing:

output_file_stream << '\n';

will write either a LF (eg. under unix) or CR/LF (eg. under Win32).

There's a bigger issue: What value(s) does it write? Don't assume ASCII
encoding if you expect your code to be portable.

The bottom line, really, is that it doesn't matter at all how many
characters are actually written. There are two possibilities:

1) You are writing a text file. The library will do the Right Thing
without you having to worry about it (as long as you open the file in
text mode).

2) You are writing a binary file. It will output exactly what you tell
it to (as long as you open the file in binary mode). You have complete
control.

If you are dealing with a file format that specifies things like how a
newline should be written, then clearly you are dealing with a binary
file, not a text file (if it were text there'd be no reason to specify
it - it's inherent in the system). So stop trying to find a way to trick
the library into doing what you want it to do and use a binary file.

-Kevin

 

[Kevin Frey]

I think the question has been misunderstood. Nowhere did I say that
the specification dictates what the end-of-line convention is. Rather,
the specification says that this is the requirement depending on
*what* the standard end-of-line convention is for the platform.

Let's ignore the issue of non-ASCII platforms for the moment since
that is a completely different kettle of fish in terms of complexity -
particularly when I am talking about a document interchange format
that must be ASCII.

Does anyone have an ideas for solving my problem, rather than:

a. Second-guessing why I need to solve the problem.
b. Telling me that I don't really need to solve the problem.

Thanks

Kevin.

 

[Shane Beasley]

I think the question has been misunderstood. Nowhere did I say that
the specification dictates what the end-of-line convention is. Rather,
the specification says that this is the requirement depending on
*what* the standard end-of-line convention is for the platform.

Dumb question: What good's a portable document format (that's what
Acrobat uses, right?) whose end-of-line sequence is platform-dependent
-- and therefore, by definition, unportable? Or is it simply that
you're allowed to use any of several end-of-line sequences, including
-- but not limited to -- the one typically used on your platform?

In the latter case, then your solution lies in binary I/O, as Gianni
mentioned earlier. You get to write exactly how many bytes you need
per line, and you can cap it off with whatever end-of-line sequence
you feel like writing (typically '\r' or '\n' or "\r\n" on ASCII
systems like the ones you support). If the PDF format is truly
portable, that ought to be sufficient.

If not... There's no way to detect the end-of-line sequence without
checking when your program runs or hard-coding it per system ahead of
time. And yes, "checking" involves writing an endline to a file and
opening it *in binary mode* to see what was written.

Does anyone have an ideas for solving my problem, rather than:

a. Second-guessing why I need to solve the problem.
b. Telling me that I don't really need to solve the problem.

How about this:

c. Telling you that your problem isn't what you think it is.
d. Telling you a way to solve the (actual) problem.

At least, that is what I hope to have accomplished here. Good luck!

- Shane

 

[Ron Natalie]

a. Second-guessing why I need to solve the problem.
b. Telling me that I don't really need to solve the problem.

Is this what you want

ostringstream oss;

oss << '\n'; // textual newline.

string end_of_line_sequence = oss.str();

Fills the string with whatever the implementation defined end of line
sequence is.

 

[Kevin Goodsell]

Is this what you want

ostringstream oss;

oss << '\n'; // textual newline.

string end_of_line_sequence = oss.str();

Fills the string with whatever the implementation defined end of line
sequence is.

Does it? I considered that, but figured it would not do the end-of-line
translation in that case since it is not being written to a file. I was
sort of guessing that this translation would occur in the filebuf class.

-Kevin

 

[Ron Natalie]

Does it? I considered that, but figured it would not do the end-of-line
translation in that case since it is not being written to a file. I was
sort of guessing that this translation would occur in the filebuf class.

Yeah, you're probably right. I guess you could always create a file somewhere
write it with text mode and read it back with binary.