The bug was due to a newline that you didn't account for. It wasn't due to your algorithm: if you correctly removed the newline while retaining the overall original algorithm, the bug would have been fixed. That you fixed the problem by implementing a different algorithm doesn't mean that flp1969 and I were wrong about our analysis concerning your bug as posted in post #1.Originally Posted by zach
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
You seem to be oblivious to the error in the algorithm. Did you have a good look at it? You simply have it wrong. And might we please limit the discussion to the issue per se?
Yes, I had a good look at your implementation of your algorithm as posted in post #1. How do I have it wrong?
Notice that you never explained what exactly it is that you're trying to do. You only posted code and outlined a bug. So, if there's an error with your algorithm itself beyond the bug that you mentioned, no one else can find it and fix it, i.e., there is no way I can be wrong about your algorithm because it is yours, not mine. I can be wrong about my analysis concerning the bug that you mentioned.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
It might be easier if we looked at code. Here's a test data5.txt:
Here's your code from post #1 placed within a self-contained program:Code:This is a test for new lines
I've taken the liberty of adding the counter + 1 < sizeof(lineNo) / sizeof(lineNo[0]) check in order to avoid array out of bounds access, and changed the fgets call so that it is not dependent on a magic number. I also removed the gotoxy calls since they are not needed for this demonstration, and after all are non-standard so it is more tricky to come up with a portable example program.Code:#include <stdio.h> #include <stdlib.h> int main(void) { FILE *fp = fopen("data5.txt", "r"); if (fp == NULL) { puts("No data5.txt with codes."); return EXIT_FAILURE; } int lineNo[] = {0, 1, 0, 1, 0, 1, 0}; int counter = 0; char str[35]; while (counter + 1 < sizeof(lineNo) / sizeof(lineNo[0]) && fgets(str, sizeof(str), fp)) { if (lineNo[counter + 1] == 1) { puts(str); // *** } counter++; } fclose (fp); return 0; }
Here's the output from compiling and running the above program with my data5.txt:
We can see that when lineNo[counter + 1] == 1, the corresponding line from data5.txt is printed, but it looks like when lineNo[counter + 1] == 0, the corresponding line from data5.txt is not printed, yet a blank line (i.e., a newline on its own) is printed. This matches your statement from post #1:Code:This is test new lines
Now, let's change the code to remove the newline from fgets:
Now, when we run the program with the given data5.txt, we get:Code:#include <stdio.h> #include <stdlib.h> #include <string.h> int main(void) { FILE *fp = fopen("data5.txt", "r"); if (fp == NULL) { puts("No data5.txt with codes."); return EXIT_FAILURE; } int lineNo[] = {0, 1, 0, 1, 0, 1, 0}; int counter = 0; char str[35]; while (counter + 1 < sizeof(lineNo) / sizeof(lineNo[0]) && fgets(str, sizeof(str), fp)) { if (lineNo[counter + 1] == 1) { str[strcspn(str, "\n")] = '\0'; puts(str); // *** } counter++; } fclose (fp); return 0; }
This demonstrates that indeed the bug has to do with the combination of the newline being left in the buffer from fgets, and puts writing its own newline.Code:This is test new lines
Last edited by laserlight; 09-29-2019 at 02:42 PM.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
"This demonstrates that indeed the bug has to do with the combination of the newline being left in the buffer from fgets, and puts writing its own newline."
No laserlight quasi new lines are printed because of counter ++ ( line 25) causes the cursor to drop when lineNo = 0. You shouldn't change the code in an attempt to justify your point, that is very dirty. You simply didn't have the insight to see how the algorithm was producing new lines. Covering up that you missed the point by changing the code is despicable.
Last edited by zach; 10-01-2019 at 01:52 AM.
Insulting a member for genuinely providing analysis is despicable. I'm not covering up anything. You can see for yourself that my code example does indeed produce the output you described. Removing the gotoxy call makes no difference because you don't have a gotoxy call when lineNo[counter + 1] == 0, and the gotoxy call when lineNo[counter + 1] == 1 happens before the puts call.Originally Posted by zach
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
If you do want to insist that I'm wrong, then do the same thing: come up with the smallest and simplest compilable program that demonstrates the problem you described in post #1. Provide the test input, expected output, and actual output.
In fact, this is one of the best ways to proceed when asking for help: people could compile and run your program for themselves and maybe tweak it to see if their suggested fix worked. There's no point insulting people for a supposed "lack of insight" when you didn't provide a full picture for insight in the first place.
Last edited by laserlight; 10-01-2019 at 03:29 AM.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Actually, you can just modify my code from post #23, and you may want to change the test input too. I'm not going to do that for you because I'm not keen to venture a guess as to how you're working with the non-standard constructs, but after re-examining your point about gotoxy changing the behaviour, I can see what you mean since counter is incremented on every iteration, yet used in the gotoxy call.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
You simply don't have the wisdom to follow the while wend loop for a few cycles in order to see what the outcome is on the screen. That is, without butchering my code about to support your erroneous position. Which, by the way, is enough to make anyone angry. You need someone to take you by the hand and explain to you how the algorithm inserts empty lines. "you didn't provide a full picture for insight in the first place": I cannot explain to a fish that it is swimming in water, you are missing a few IQs my dear. I am not going to continue this discussion ad infinitum.
I use Linux, so I cannot see what the output is on screen because I cannot compile a non-standard program that uses gotoxy. That's another reason why providing a test program with test input and output is important.Originally Posted by zach
You can stop insulting me now. The fact is that I explained my position, you merely asserted without proof that that was not the problem, but rather it was with your algorithm. Asking for an explanation is a far cry from "hand holding".Originally Posted by zach
As I implied in my previous post, back in post #16, instead of just claiming without proof that "the cause was the algorithm", you could have pointed out that because counter is incremented on every iteration and used in the gotoxy call, it affects the positioning by gotoxy such that lines appear to be skipped.
It's that simple, but because you neither provided a small program with test input and output nor included code to remove the newline in your code, flp1969 identified another potential problem that turned out to be tangential, and that reasoning made sense to me because there was no evidence to the contrary.
Last edited by laserlight; 10-01-2019 at 04:39 AM.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
You have drawn a line under the discussion, for which I thank you. I will do the same: I did explicitly describe the nature of the bug to you in very clear terms. Therefore the simplicity of the bug on the one hand, and you doggedly ignoring my explanation on the other hand, gave rise to my impression that you were not being sincere with me. That in turn caused my expressed disrespect of your vast experience and knowledge with which you make so many valuable contributions to discussions in this forum. That I regret. With these words I would please also like to close the discussion.