about: fstream << "\r\n"

[Rate Spring]

hi, in win2000 and VC6, I operate a txt file. When I write a line data into
file and add "\r\n" at the end of line, I find:

fstream << "\r\n" write 3 chars : 0D 0D 0A
fstream << "\n" write 2 chars : 0D 0A

why?

 

[John Harrison]

hi, in win2000 and VC6, I operate a txt file. When I write a line data
into
file and add "\r\n" at the end of line, I find:

fstream << "\r\n" write 3 chars : 0D 0D 0A
fstream << "\n" write 2 chars : 0D 0A

why?

Because you've opened the file in text mode. '\n' is the newline character
and \r\n is the end of line sequence on Windows operating systems. You
will also find that the reverse translation happens on input, \r\n will
read as a single character '\n'. So when you read back you'll get the
exact same characters you output.

Normnally this is convenient, it lets you port programs between Unix and
Windows say. But if you don't want it to happen then open the file in
binary mode.

fstream file("something.dat", ios_base:ut|ios_base::binary);

john

 

[Sharad Kala]

hi, in win2000 and VC6, I operate a txt file. When I write a line data into
file and add "\r\n" at the end of line, I find:

fstream << "\r\n" write 3 chars : 0D 0D 0A
fstream << "\n" write 2 chars : 0D 0A

John has given you the answer. To see it more clearly feed a Windows files
to some Unix compiler. Say compile with g++ on windows with cygwin and feed
it a Windows file. It will misinterpret the file then.

-Sharad

 

[John Harrison]

John has given you the answer. To see it more clearly feed a Windows
files
to some Unix compiler. Say compile with g++ on windows with cygwin and
feed
it a Windows file. It will misinterpret the file then.

Yes, I should have said it lets you port *code* between Windows and Unix,
it's of no help porting the file itself.

john

 

[Robbie Hatley]

hi, in win2000 and VC6, I operate a txt file. When I write a line data into
file and add "\r\n" at the end of line, I find:

fstream << "\r\n" write 3 chars : 0D 0D 0A
fstream << "\n" write 2 chars : 0D 0A

why?

In DOS and Windows, a newline is two bytes:
carriage-return (0x0D) followed by line-feed (0x0A).

'\n' is CR-LF, or 0x0D0A.

'\r' is just CR, or 0x0D.

Hence "\r\n" is 0x0D0D0A.

(In Unix or linux, a newline is just one byte,
so none of the above applies.)


--
Cheers,
Robbie Hatley
Tustin, CA, USA
email: lonewolfintj at pacbell dot net
web: home dot pacbell dot net slant earnur slant

 

[Ron Natalie]

In DOS and Windows, a newline is two bytes:
carriage-return (0x0D) followed by line-feed (0x0A).

'\n' is CR-LF, or 0x0D0A.

Completely and totally incorrect. '\n' is a single character on every compliant
C and C++ compiler in the world. It is the C++ streams and C FILE streams
that map the single '\n' character into something implementation specific (which on
most non-UNIX platforms is 0D 0A.

 

[Robbie Hatley]

Completely and totally incorrect.

Perhaps I should clarify. Replace "is" with "maps to":

'\n' maps to CR-LF, or 0x0D0A

'\n' is a single character on every compliant
C and C++ compiler in the world.

I wrote "In DOS and Windows", not "In compliant C and C++
compilers".

Newline is a single character in registers and RAM during
program execution, yes, but must be converted to 0x0D0A
when talking to MS-DOS or MS-Windows.

It is the C++ streams and C FILE streams that map the
single '\n' character into something implementation
specific (which on most non-UNIX platforms is 0D 0A).

I don't know about "most non-UNIX platforms", but yes,
C and C++ implimentations on MS-DOS and MS-Windows do
have to convert '\n' to 0x0D0A (outbound) or 0x0D0A to
'\n' (inbound) when talking to the operating system.
This is what I was trying to say in my original post.

--
Cheers,
Robbie Hatley
Tustin, CA, USA
email: lonewolfintj at pacbell dot net
web: home dot pacbell dot net slant earnur slant