[C++] carriage return with fputs()?

7,137 · May 17, 2011

Okay, it's 2am, and I'm at my wits end.

I'm trying to output a bunch of variables to a file, with 2 numbers and a carriage return on each line.

I have two global int arrays declared all with variables in them.

void FileOutput()
{
	FILE *f = fopen ("myfile.txt", "wb");

	if (f == NULL) die("Couldn't open myfile.txt for writing, sorry");
	else {
		int x;
		char temp_string[20];
		for (x = 0; x &lt;= 4; x++)
		{
			sprintf(temp_string, "%i %i \n", x_pos[x], y_pos[x]);
			//printf("%i %i", x_pos[0], y_pos[0]);
			printf("Calm down sir, PLEASE\n");
			fputs (temp_string, f);
		}
	fclose(f);
	}

	printf("Don't worry sir, I'm from the internet\n");
}

Now, it puts it in the file fine, however, it all comes out as one line. The output on the screen comes out fine and I get carriage returns as expected there, however. I'd like it to come out this like this:

82 103

49 134

953 535

354 53

3535 234

The variables are purely aribtrary, this is an extension of a tutorial I'm following (I'm doing Wii homebrew development). I have to say, I've been doing programming for a while, and yet, I've never come across an issue quite like this that I haven't been able to resolve so easily.

Shoving \n everywhere does nothing (in regards to file output). I've tried injecting it when doing fputs() and also at the sprintf part, neither work. Honestly running out of ideas here. Anyone able to give me a hand figuring out what I'm doing wrong here?

Major thanks in advance.

2,574 · May 17, 2011

Well carriage return is \r

\n is new line.

7,137 · May 17, 2011

On 17/05/2011 at 01:03, Garry said:

Well carriage return is \r

\n is new line.

Well, that's what I meant. I thought carriage returns and new lines are one of the same?

2,574 · May 17, 2011

It's been ages since I meddled in C++ but just try \r\n for me.

7,137 · May 17, 2011

Holy moly... dude, I LOVE YOU. It worked! haha!

1,109 · May 17, 2011

Windows usually treats \r\n as a newline, whereas in unix/linux we just use a \n. Blame Microsoft for the inconsistency.

2,574 · May 17, 2011

On 17/05/2011 at 01:08, The Teej said:

Holy moly... dude, I LOVE YOU. It worked! haha!

Hehe. Always glad to help where I can. :)

Garry for MVP :D

7,137 · May 17, 2011

Garry for MVP indeed! haha!

I've spent a good couple of hours trying to figure out this issue by myself... crazy that all took it was 2 extra characters. Ah, the blessings and curses of programming!

6,190 · May 17, 2011

On 17/05/2011 at 01:08, Flawed said:

Windows usually treats \r\n as a newline, whereas in unix/linux we just use a \n. Blame Microsoft for the inconsistency.

Not to distract from the topic, but Microsoft is not alone here. There are (or have been) at least 5 different newline combinations, \r\n being the widest employed on different Operating systems. According the Wiki, \r\n is even used in UNIX TTYs in "Raw Mode" although I'd be the first to admit that I'm no expert on the matter. If you want to get into semantics, Microsoft are arguably the ones doing it right, since both characters would have served an individual purpose in the beginning (although the purpose has long since passed). For example:

\r == Carriage Return, return the Caret to the start of the line. (Equivilent to pushing the paper back to the right side on a typewriter)

\n == Line Feed, move the caret down a line. (Equivalent to hitting the return key on a typewriter)

\r\n == Move the caret to the beginning of the line, and then down.

Based on that logic, \r\n is the one true newline. Such logic has long since been deprecated in computing, but if you're going to get into "inconsistency", Microsoft aren't the one's being inconsistent here, although a 2 character newline has long since surpassed being useful.

Thats right, I DID just make a 10 line post about the almighty newline!

1,109 · May 17, 2011

On 17/05/2011 at 01:25, Majesticmerc said:
Not to distract from the topic, but Microsoft is not alone here.

Perhaps not, but they could set an example and standardise on LF. The other main OS's, GNU/Linux, OSX, and unix all use LF to represent a line-break in text mode. It only serves to create portability problems and confuse programmers.

On 17/05/2011 at 01:25, Majesticmerc said:
According the Wiki, \r\n is even used in UNIX TTYs in "Raw Mode" although I'd be the first to admit that I'm no expert on the matter.

Perhaps so, but "Raw Mode" is not standard text mode, which is what we are discussing here.

On 17/05/2011 at 01:25, Majesticmerc said:

If you want to get into semantics, Microsoft are arguably the ones doing it right, since both characters would have served an individual purpose in the beginning (although the purpose has long since passed). For example:

\r == Carriage Return, return the Caret to the start of the line. (Equivilent to pushing the paper back to the right side on a typewriter)

\n == Line Feed, move the caret down a line. (Equivalent to hitting the return key on a typewriter)

\r\n == Move the caret to the beginning of the line, and then down.

CRLF is unnecessary verbosity in my opinion. I think we can agree though that standardisation would be a good thing for everybody.

On 17/05/2011 at 01:25, Majesticmerc said:
Based on that logic, \r\n is the one true newline. Such logic has long since been deprecated in computing, but if you're going to get into "inconsistency", Microsoft aren't the one's being inconsistent here, although a 2 character newline has long since surpassed being useful.

The bigger problem is not necessarily how a newline is represented, but how the compiler's C library handles the escape characters in I/O functions such as printf(), fwrite():

Quote

The C standard only guarantees two things:

1. Each of these escape sequences maps to a unique implementation-defined number that can be stored in a single char value.

2. When writing a file in text mode, '\n' is transparently translated to the native newline sequence used by the system, which may be longer than one

character. When reading in text mode, the native newline sequence is translated back to '\n'. In binary mode no translation is performed, and the internal representation produced by '\n' is output directly.

Source.

The second one is interesting. I suppose technically, It means the OP's compiler/C library isn't standards compliant.

On 17/05/2011 at 01:25, Majesticmerc said:
Thats right, I DID just make a 10 line post about the almighty newline!

No need to be ashamed, at least you put some thought into it :D

1,109 · May 17, 2011

On 17/05/2011 at 13:53, Flawed said:

Quote
The C standard only guarantees two things:
1. Each of these escape sequences maps to a unique implementation-defined number that can be stored in a single char value.

2. When writing a file in text mode, '\n' is transparently translated to the native newline sequence used by the system, which may be longer than one

character. When reading in text mode, the native newline sequence is translated back to '\n'. In binary mode no translation is performed, and the internal representation produced by '\n' is output directly.

Source.

The second one is interesting. I suppose technically, It means the OP's compiler/C library isn't standards compliant.

I did a little investigating, and MinGW (GCC for windows) at least does automatically translate a \n into a CRLF for you.

Code:

Terminal output:

Textmode file:

Edit: I just noticed you are opening the file with a "wb" mode. That indicates binary mode. Try just "w" for text mode. That seems to be the problem.

8,753 · May 17, 2011

I always use \n, whether it's C++, C#, Windows or Linux. And it always works as intended, although I'm not sure of the specifics. A very dumb editor like Notepad doesn't recognize \n as newline I think, but anything better than that (Wordpad, Notepad++, Visual Studio etc.) will display the text as intended, and reading line-by-line using any standard programming library (C++, Java, etc.) will also recognize \n as newline.

Just stop using notepad and you should be set. :p

1,109 · May 17, 2011

On 17/05/2011 at 16:07, Dr_Asik said:

I always use \n, whether it's C++, C#, Windows or Linux. And it always works as intended, although I'm not sure of the specifics. A very dumb editor like Notepad doesn't accept \n as newline I think, but anything better than that (Wordpad, Notepad++, Visual Studio etc.) will display the text as intended, and reading line-by-line using any standard programming library (C++, Java, etc.) will also recognize \n as newline.

If the compiler and the C library it links programs with are standards compliant it will. Unfortunately a lot of compilers aren't very standards compliant.

However in the case of the OP, as stated in my last post, he's opening the file in binary writing mode (wb), when he should be using text writing mode (w). I tested it myself in Windows XP, and it works fine in text writing mode (w) with MinGW (GCC for windows).

8,753 · May 17, 2011

Quote
If the compiler and the C library it links programs with are standards compliant it will. Unfortunately a lot of compilers aren't very standards compliant.

I don't know of any recent compiler that does not implement that correctly.

Quote
However in the case of the OP, as stated in my last post, he's opening the file in binary writing mode (wb), when he should be using text writing mode (w).

That's true. From Wikipedia:

Quote
When writing a file in text mode, '\n' is transparently translated to the native newline sequence used by the system, which may be longer than one character. When reading in text mode, the native newline sequence is translated back to '\n'. In binary mode no translation is performed, and the internal representation produced by '\n' is output directly. http://en.wikipedia.org/wiki/Newline#In_programming_languages

However, as I said, the \n character is interpreted correctly by virtually anything but Notepad, including the standard C++ library.

Btw, since the language is C++, why not use the C++ standard library? Would have avoided the whole discussion in the first place.

void FileOutput() {
	ifstream f("myfile.txt");
	if (!f.is_open())
		die("Couldn't open myfile.txt for writing, sorry");
	else {
		for (int x = 0; x &lt;= 4; x++) {
			f &lt;&lt; x_pos[x] &lt;&lt; " " &lt;&lt; y_pos[x] &lt;&lt; endl;
		}
	}        
	cout &lt;&lt; "Don't worry sir, I'm from the internet" &lt;&lt; endl;
}

Fool-proof and much more simple!

1,109 · May 17, 2011

On 17/05/2011 at 16:36, Dr_Asik said:
Btw, since the language is C++, why not use the C++ standard library? Would have avoided the whole discussion in the first place.
void FileOutput() {
	cout &lt;&lt; "Don't worry sir, I'm from the internet" &lt;&lt; endl;
}
Fool-proof and much more simple!

AFAIK, 'cout << "Don't worry sir, I'm from the internet" << endl;' and 'cout << "Don't worry sir, I'm from the internet\n";' are analogous, that is, the standard library translates both the endl manipulator and the '\n' escape sequence into the system (OS) specific newline character(s), which in the case of Windows is CRLF, and in GNU/Linux is LF.

With regard to using the C++ standard library, I tend to agree. If you want to write C++, use the C++ extensions. The OP's code is just plain C, and so it can just be compiled as C without the C++ bloat. That being said, I think we should cut him some slack given that he's probably just experimenting.

Sign In

[C++] carriage return with fputs()?

Question

The Teej

Link to comment

Share on other sites

14 answers to this question

Recommended Posts

Garry

Link to comment

Share on other sites

The Teej

Link to comment

Share on other sites

Garry

Link to comment

Share on other sites

The Teej

Link to comment

Share on other sites

Flawed

Link to comment

Share on other sites

Garry

Link to comment

Share on other sites

The Teej

Link to comment

Share on other sites

+Majesticmerc MVC

Link to comment

Share on other sites

Flawed

Link to comment

Share on other sites

Flawed

Link to comment

Share on other sites

Andre S. Veteran

Link to comment

Share on other sites

Flawed

Link to comment

Share on other sites

Andre S. Veteran

Link to comment

Share on other sites

Flawed

Link to comment

Share on other sites

Recently Browsing 0 members

Choose your Ad Blocker