Ah, the "% d", was the problem. I really thought I had fixed that
But what does flushing do exactly? I thought you could just switch between read and write when you used "r+" or "w+" with the fopen function?
Ah, the "% d", was the problem. I really thought I had fixed that
But what does flushing do exactly? I thought you could just switch between read and write when you used "r+" or "w+" with the fopen function?
you could switch, but you have to flush the file inbetween
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
So like this?
Code:#include <stdio.h> #include <stdlib.h> FILE * fptr; int main() { char letter; int i; fptr = fopen("C:\\abc.txt", "r+"); printf("Enter: "); scanf("%d", &i); fseek(fptr, (i-1), SEEK_SET); fputc('*', fptr); fseek(fptr, 0, SEEK_SET); fflush(fptr); printf("The file looks like this: \n"); for (i = 0; i < 26; i++) { letter = fgetc(fptr); printf("The next letter is %c\n",letter); } fclose(fptr); getchar(); // This should be changed someday. getchar(); getchar(); return 0; }
Does it work?
Glad to see you're paying attention.Code:// This should be changed someday.
Like I think I said, these two calls
are exactly the same as a single call to rewind(fptr). Why not use that?Code:fseek(fptr, 0, SEEK_SET); fflush(fptr);
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
I think it works, but I don't notice a difference.
The reason is that I'd like to learn one thing at a time, besides: I now know that it is always necesary to flush the buffer before switching between reading and writing.
And I took your advice:
ThanksCode:do { puts("Press enter to quit."); getchar(); } while (getchar() != '\n');
Last edited by omnificient; 03-03-2008 at 01:42 PM.
Have you tested your code?
You actually need to press Enter twice to exit this programCode:#include <stdio.h> int main() { do { puts("Press enter to quit."); getchar(); } while (getchar() != '\n'); }
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
Yes, I tested it. The user only has to press enter once.
If that's the case, you probably had a left-over newline in the input buffer from a scanf() or some such - as it's quite clear that if there is NOTHING in the input buffer, the first getchar() will wait for a newline and consume it, the second one will have to wait for ANOTHER newline.
Have you actually tested the code posted above by vart?
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Well matsp, as I said: I indeed tested the code. I did realise, after vart pointed it out, that there is some \n left from another scanf() or something.
It works, so is there a problem with the loop I have used here?
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
So that would mean using another getchar()? The problem that I then create is that the user now does have to press enter twice.
Maybe a while loop?
No, it means moving the gechar() from INSIDE the loop, to outside the loop.
Your current code expects the input to be '\n', '\n'. So your getchar() inside the loop "eats" the first newline, then the getchar() in the while-condition eats the final newline.
But consider that scanf() left an 'a' in the input buffer, as well as your expected two newlines. So your first getchar() eats the a, the while() one eats a newline and the user doesn't get to press enter before it exits. Other options exist.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
So will the getchar() in the while statement is not only used to check if something is true, but it will actually be presented to the user?
Let me explain what is happening here:
Every time the loop executes, you:Code:do { puts("Press enter to quit."); getchar(); } while (getchar() != '\n');
- Print a message.
- Discard a single character from the input stream.
- Get another character from the input.
- Start executing the loop at the beginning again if this character is not a '\n'.
A few problems to note with this approach:
- Only every other character is checked against a newline.
- A message is printed every two characters.
So you might try to fix it by using this . . .
Right? Because now every character is checked against '\n'.Code:do { puts("Press enter to quit."); } while (getchar() != '\n');
Not quite . . . what happens if the input stream contains "\nexit\n"? You'll get "Press enter to quit." printed six times!
So here's what you really want to do. You want to print the message once, and then eat as many characters as you need to until you get a '\n'. (Checking every character you read against '\n', of course.) In other words:
Of course, that simplifies to:Code:puts("Press enter to quit."); do { } while (getchar() != '\n');
. . . which is what I had in the first place, I believe.Code:puts("Press enter to quit."); while(getchar() != '\n');
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
I see how it works now. Thanks for the explanation.