I fear it wouldn't be easy for me to explain that RT

I'll try what you said about the spreadsheet and what GazL and others said about writing it down. There's also something else that I'll be trying as well that might help.

But thanks for explaining the above nonetheless.

Can I still please ask that you do try to explain, this specifically:My reason being is that it would be helpful to learn how you would trace through that one loop line of logic, and it would give your fellow LQ members some insight into exactly how you are approaching these types of analyses. Otherwise things here stand to continue with each of us offering various techniques and not seeing that any message has been conveyed or interpreted as anticipated.

1 members found this post helpful.

While I'm not really sure if you mean as in, "doing it in my head", or "writing it out" (be that in a spreadsheet or on paper); as much as I don't really like to assume too many things, I'll assume you mean the former (doing it in my head)...

Perhaps it's easier to say; it's not particularly hard to imagine that the while loop (the most outer loop in my original program) calls fgets() to upload a line from the file into the array, then the for loop scans through that same line looking for a hash, then depending on what it finds, does x,y or z (whatever the if statements within dictate), then the program repeats the process until it's finished reading all of the lines in the file. That's how I would think about it in my head, but trying to follow the for loop in detail just in my head with the if's in it, that's where I end up getting lost.

Even if I loaded the program up in gdb, and then set a breakpoint, then typing "n" to run statements one by one, it's still very difficult to try and keep track of where exactly it's at, and why it's at where it's at - even if I know what I intended and tried to do/write, what's on the line(s), etc. I know it sounds funny, I know, but it would still be the same story regardless of exactly what's on the line, be that your example line or anything else. It's ok when I look at your post #105, because I can clearly see the content of each array element, the value i has each time, and the result of the test each time. But gdb for one doesn't exactly show me that kind of detail, and even if I print the value of for example i, I tend to lose track of it - particularly where there's multiple lines in the file to process.

It's ok with other people's non-programming related technical problems/questions that I respond to here, because I can generally just focus on one possible cause/reason/etc at a time, without having to try and keep track of multiple values, variables, etc all at once. And even with multiple variables/details, it's still much easier because for lack of a better answer, I can to a large extent focus on what the program is supposed to do at a high or high-ish level, and if it isn't working as it should, think of what situation could be the cause of that, then think about the OP's situation/what they've described about their problem, etc. In any case, it's similar to "you can know what a kernel is and does, but it doesn't mean you can write one yourself, even if you can compile one yourself".

Not really sure how else to explain, so that's probably the best I can explain it.

Thanks. It does help. I think there are benefits with doing things in one's head, but a point of concern here is that thinking through the progress of an algorithm solely within one's mind can rapidly lead to a situation where you have too much to remember and consider. I know you are aware of this, and suggest that you consider various ways to reset things if or when you do get into the too highly detailed situation, so that you can find a clear way to get back to a known state of clear understanding.

Shorter comment: Great, you're doing it in your head. I'm telling you that you're missing stuff and that it's not working.I think here is a disconnect. What I was asking about was that one line, and one loop. You are talking about the entire processing algorithm. This is both OK, as well as a problem. My point is to be able to have the capability to identify a point where you may need to debug, or at least test and verify so that you know for sure it does what you need it to do, for all your test cases. That for() loop processes each line. The outer while() loop just introduces each line to the for() loop, or this should be the intention. Therefore the recommendation is to debug, refine, and test thoroughly the for() loop which processes each individual line. After which point you should then determine whether or not the while() loop is performing as needed.

By combining analysis of both loops together in your mind analysis, or in a paper analysis means that you are failing to segment the debug of things and keeping things too complicated at this time.

Shorter comment: Please debug ONLY that for() loop, because it seems clear to me that it can be written differently, such as the end test condition is not something I recommend using the way it is coded.As far as the debugger goes, it can be tedious, no easy answer because it does take time. I've demonstrated that I use GDB through emacs in my blog about debugging. Using it in that manner, you can have a watch window. A watch window is where you can specify variables that you wish to "watch", so at each breakpoint and at each single step, the variables in that watch list/window, get updated. This provides convenience, but is not absolutely necessary.

One does not need to use a watch window, or to set variables up for being watched. Even if you use the command line GDB, if you declare a variable as being watched, I believe what happens when you step, or break, or maybe only if there are changes to a watched variable, the new prompt, plus output, includes the changes to the watched variables.

But not using the concept of watching at all is perfectly fine. One can just print 'p' from the debugger at each stopping point, as I demonstrated in an earlier post and also as shown in that blog. The up arrow helps, or just typing repetitively the same 4, 5, or 6 commands in secession, so that you can fill out your table in your spreadsheet.

The bottom line is that it is all organizational. At each step, verify the variables needed. Do not run or take another step until you've verified, and be very cautious about choosing to run. Instead single step, or set enough breakpoints so that when you hit library calls like printf(), you can step over them, or run and hit a breakpoint so that you do not miss the next iteration of your loop.

And on top of this, you can write things into a spreadsheet, notepaper, scrap paper.*** see below

I no longer do this level of detail, but only because previously I have done this detail, and have learned from those experiences.

You do not have those prior experiences, so the recommendation is that you do try to practice something like this tedious form of debugging.

While there are different ways to do this, single step, breakpoints, watch variables, or printing in the debugger, these tedious steps and the attention to diagnosing one area of code completely will help you as you progress to more complex designs.

Shorter comment: I KNOW it's pain in the backside and it takes a LOT of time and effort, but ... you're going to benefit from it.

*** Addendum: About writing things down. Recent place I worked, "the boss" would print out lots of stuff and bring it to me to ensure that I "saw" it, that I knew about it, it was just his way. Got it. Caused me to have a lot of leftover stuff, which I put in a pile on one of my shelves.

Guess what I largely did with that?

I'd flip over the printed junk, because it was all single sided, tree waste, and I'd use that as scratch note paper for design discussions, and detailed analysis.

So when I say "use a spreadsheet" is does not mean EasyCalc, Excel, or a program, it can be on a piece of paper, and that typically is how I do it.

When I talk about GDB and either watching variables or printing variables, those are notifications and information which you "see", but the storing of it, is manually writing it with a 0.5mm mechanical pencil (just my style) onto that scrap paper, in some form of table/organized fashion.

So I'd have a sheet where I analyzed, "line 1\n\0".
I'd have a sheet where I analyzed, "# this is a comment line\n\0"
I'd have a sheet where I analyzed, "This is a partial # comment line\r\n\0"
I'd have a sheet (maybe multiple ones) where I analyzed, "$%&@!()FGJUIOLEHJTGF*()FYH_(FUYE)GF_I*)(EYH(F0ut0puw80frrg-09uf08iyt-9wuf9-53\b\b\\b\b\b\t\t\t\t\r\n\0\r\r\r\0"

I'm never saying this is easy, a throw in the bucket, but I am trying to convey a path to follow, agreeing that it takes a lot of commitment, but also showing the benefits from it.

2 members found this post helpful.

At some stage, one calls in a peer review and in this case the peers appear to be participants in this thread.

Since the participants in this thread are remote (to you), it helps to put it down in a step by step output (with the help of and so forth.

Do that with every suspect variable.

If you put it in a spreadsheet, you can sort, group etc.

OK

1 members found this post helpful.

some people/organizations spend many hours on a project before putting it into production. This requires logical boards and flow charts all put on paper and/or chalkboards, or white boards. Before one letter of code it written into a file.

1 members found this post helpful.

Thanks guys. Sorry I took a little while, but I've had other things that got in the way.

I tried debugging it with gdb, while printing the values of i and content[i] and writing it down in a spreadsheet in LibreOffice Calc, but gdb was only showing me the values of the first non-space character in the content array. I also tried using the printf astrogeek posted earlier on, but that wasn't showing me the value of all of the elements for the content array either. So it's hard to do it on paper if I can't see what the current value of the content array element is.

So I don't know how I'm supposed to figure it out now.

GDB will show you the entire array.
It can show you the whole array or character by character.

Example code:Sample GDB session:What do you see instead when you try this?

1 members found this post helpful.

Thanks RT. I tried what you said above and while I can see what you mean. But trying to follow just the for loop in my head, or even trying to understand the steps it's taking to write it down (on paper or in a spreadsheet) is still virtually impossible. Even trying to use gdb to figure out the steps it's taking is still virtually impossible for me. Let alone trying to work it out like GazL posted in post #99. I'm sorry, but I'm honestly lost trying to figure out what GazL did in post #99 - I only know that's what's happening because GazL posted it before, whereas had they not posted that, I'd still be in the dark about all of that.

I done what you done above, and here's gdb's output for you;

(the above gdb output is from the same code as GazL quoted in post #99)

James, can you follow that code in your head, or do you have the same problem as with understanding the 'for' loop? It seems you're having problems visualising the individual steps in a program and I'm trying to figure out what it is that's blocking your understanding.


You've told us before that you're a visual learner, perhaps this series on youtube might help. I've not watched it myself, but I recently watched the C++ tutorial series from the same guy and it was pretty good, so it might be worth a look.


I know it's pretty much a dead language at this point but I'm thinking you might actually benefit from learning a teaching language like BASIC, even if only to get you used to seeing through programs to the individual steps they take.


P.S. I'm a 'he'. I know it's all the rage now, and it's probably due to my age, but I find the use of 'they' as a gender neutral third person singular personal pronoun really jarring. Don't worry, I'm not offended, just saying. I also remember a time when "bad" meant bad, "gay" meant happy, and "sick" meant a call to the doctor! *sigh* Oh well...

2 members found this post helpful.

You used the identical technique to debug code from earlier.

The results of that debug session are correct.

Thanks again guys.

No. But yes, it's the same problem as before - trying to visualize each step in my head that is. Reading the code itself is ok, but trying to step through it, particularly in my head is another story.

I'll have a look at the video you linked though.

for loop looked as a while loop.

the for loop does the same as a while loop. it only consolidates the three into one line.

for loop
here go back to top and don't stop doing that until condition has been met.
if condition has been met, continue with next step.


example
where adding to for formatting purposes.
gets
removes the last , (coma and adds the period) . at the end.

okeydoke. 'for' syntax is a little awkward, but 'while' is pretty straight forward, which is why I wanted to check it wasn't that.

Maybe the vids will help it click with you. At this point I'm out of other ideas.

That's ok GazL. Thanks a lot for all of your help, I very much appreciate your help and interest.

Like I said before it's not really the code itself/the "syntax", or even the concepts by themselves that's the problem(s). It's trying to follow it and predict what the program is likely to do next, and the next move the computer going to make - basically "thinking like a computer". That's the real problem - it basically goes back to what astrogeek was talking about before (trying to think in terms of understanding and particularly following an algorithm). While loops seem to be particularly tricky, even generally speaking (unless it's a very short and simple program that for example (but not necessarily limited to) just adds a few numbers together and prints the result) it's difficult.

Hopefully I'll get some time to watch that video either tonight or tomorrow sometime. And maybe Umlet another member suggested privately to me may help. In any case, and like you, I'm almost outta ideas on what I can do about it too.

Thanks again GazL.