NevemTeve gave a perfectly good answer back at post #33.

2 members found this post helpful.

Only if the leading char is # and not in the middle of after the string (line).

I sit with pie applied to face, sort of. TWO whopping posts before my first here, has what GazL has just pointed out, and I fully agree that it validates my entire point here.+infinity Stop looking at the forest and concentrate on the trees.No you don't, you're just being painfully polite, but everytime you write this, you append a "but ..." and then proceed to write an encyclopedia.
I've been trying to say, do NOT worry about a fully blown 1,000 line program, worry about this one task, get it done, get it done fast and efficiently.
Please see NevemTeve's very perfect code for that.My common theme here is "over try" and you improperly try, because you go off on tangents, focus on the fact that I used the term boolean, and get stuck on that. You never seem to run the debugger, or if you do, you just "run" the program, you do not seem to single step, nor inspect variables, or work effectively as you've been advised to do. Otherwise you'd get to the bottom of some rudimentary mistakes on your own, and with far less churn and effort.

This is repeated advice. Rather wish you would actually work at learning to debug and paying attention to the results and impact of each statement. This also is something which phil.d.g, along with others have tried to guide you towards. Because "giving" someone a full answer doesn't always work. I fully do not admonish NevemTeve's post of exactly that, I find it makes my point. The fact that you didn't heed it, recognize it, or apparently even try it, is a common and disappointing theme.

You are learning, do not get discouraged, but do understand that I'm also not going to stand by and cheer you for posting. I'm trying to get you to turn on the switch of effort with paying attention to debugging and the impact of each code line you write and each change you make to it.

I do not need an encyclopedia in response here, just saying. Instead, what I'd like is for you to use NevemTeve's example, and ONLY their code, along with the very minor support things you need, to validate that they've shown you the way, or at least one way, and that it is effective. Then please consider further questions to expand that topic.

1 members found this post helpful.

That was what my original solution supported, but James said he didn't want a # in the middle of a line to be flagged as a comment.

1 members found this post helpful.

I was going to comment on this is over kill but held my tongue. plus what usage is this for, a C program to find # as a comment which as far as I know mostly if not only used in bash?
geany open and use find on it, or anything with the leading # is a comment else it is not, then be done with it.

1 members found this post helpful.

Yeah, I occasionally get carried away. Probably best to call me out on it when you see me do that.

So, you know how to solve the second part of this problem:

Now we just need to know how to stop. I.E. terminate the loop early.

Are you sure you don't know how to do that? We (as in just me and you) were examining code a few posts back that tried to do exactly that:

Hint: This is probably a lot simpler than you might think.

I actually do agree with your point if I was writing something I intended on others downloading and using, sorry you feel otherwise. I wasn't just trying to be polite, that doesn't help me understand anything about programming or anything else. I'm certainly not trying to write any "encyclopedia" either. I was actually also trying to be respectful while explaining why I'm trying to do what I'm trying to do.

I did see their code. I was trying not to just copy and paste, as well as trying to do what I was saying above without using pointers, to try and not make things harder. I was also trying to follow advice you gave me before about not using code I don't fully understand. I was actually planning on going back to their post later on, once I figured out how to do it without pointers involved.

Well, either way, it's not on purpose. I think with all respect you're misunderstanding how I learn and my learning style - which clearly isn't the same as your particular learning style with all respect. You also seem to have gotten it into your head that I don't even try and work things out before posting a thread. Well, and again with all respect, I HAVE tried using gdb to debug my code (which is precisely why I compile my code with the -g option, so I CAN debug it if it doesn't work the way I intended), I HAVE used gdb to step through the individual statements in my programs, I have tried using printf() to print the values of variables used (which I even posted some code for in one of my previous posts to this very thread). I've even talked about this before, in that; nearly every time I do use gdb (or printf()), or single step through my programs with gdb, it doesn't tell me anything other than what I already know, which doesn't help me figure out what the reason for it not working is.

Example: take my original problem with the condition with my for loop; it was very obvious that the loop was terminating before reaching the hash if it was more than 32 spaces from the start of the line. But, it was NOT obvious WHY, gdb, as well as the printf()'s I tried before posting this thread did not give me any idea WHY the original for loop condition I had was wrong. It was only when astrogeek gave the hint about what it was comparing to (being ASCII), and if you read back through this thread, you'll see that while it sorta became clearer, it wasn't until astrogeek posted his printf() statement so I could SEE it's output leading up to the loop terminating combined with GazL's post #13, and some experimenting on my part that it finally clicked as to what astrogeek was saying in post #2. You seem to think that it would have just "jumped out at me" if I run gdb enough times or some such. Well, I wish you were right about that RT, but unfortunately, that's not the case.

Why did astrogeek's and GazL's post mentioned above really help? Because both of them and their posts gave me something to go on (and same for phil.d.g's posts later on for that matter), then I could actually start understanding what my for loop condition was actually doing (and I could then SEE what was really going on with it), and moreover WHY it was wrong. In other words: not just, "just trust me, it's wrong", or "this is a better way of doing it"...

In any case, while my learning style may well seem ineffective to your RT, and much as it's not your learning style; I have to do what works for me, and the example I just gave above DID work for me. Perhaps you can just step through it (and likely can, unlike me obviously), debug it with gdb or whatever, and figure out what the actual problem is, not to mention you'd also have probably 20+ year worth of experience doing just that. I don't have 20+ years of experience like you (and probably like most of the others responding to this thread), my learning style is obviously very different to yours, OK, fine. You do what works for you, I can only do what works for me. So just using someone else's code doesn't tell me WHY it's a better way of doing it, let alone why what I've tried to write doesn't work the way I intended it to. It's like saying "just trust me, it's better", well, I may as well just give up and not even bother trying to learn C in that case.

Sorry for my "encyclopedia" response, but (and sorry for the "but" too) I felt is was warranted to explain what I did above. But I won't beat that drum anymore though.

Thanks again for your time and help, I'll see what I can do. But I won't make any promises that I'll be able to get it right. I wouldn't be surprised if you're right that it's a lot simpler than what I think, it just isn't for me. Thanks again.

Yes, that's right, or for that matter, anywhere but before any other characters once again. Thanks again for all of your help GazL.

Compiling the original program from post #1 with -ggdb and using the debugger.

Setting a breakpoint at the "for ( i = 0; i < content[i]; i++ )" line.

r
(hit breakpoint)
p content
content = "line 1"
c
(hit breakpoint)
c
(hit breakpoint)
c
(hit breakpoint)
c
(hit breakpoint)
c
(hit breakpoint)
p content
content = " # comment 3"
c
(hit breakpoint)
p content
content = ' ' <repeats 33 times>, "#comment 4" (There's a bunch of garbage and other stuff after the \n for each line, you get to see it because the content array is 373 characters long, no biggie)
s
(single step between the for statement and the if(content == '#') statement)
p i
p content
p content[i]
And so forth will output the values of i, content, and content located at i
Single step until it eventually breaks out of the loop and goes to the if(str) line.

The program flow has made a conclusion and did not choose the path saying "found #"

Therefore what happened here? Why did it not get to the #?

What is the value of i?
p i
i is 32
p content[i]
content[32] is 32 ' '
Since 32 == 32, it exited the for loop.

Yes it is tedious, but it is clear what every variable value is, what is in the content[] array, and what the value of the loop index i, is.
At each and every single step you can print out i, content[i], and predict what the outcome of the next line of code is.
You also can single step as it proceeds through the for() and if() statements and the first moment it either goes to the 'str = false' line or the if(str) line, there has been a qualifying change to cause it to exit that loop. Right at that point, examine (print) the variable values and try to figure out what is going on.

That's how you debug.

whatever you're doing, ain't that.

1 members found this post helpful.

Thank you RT, while that is helpful; I did setup a breakpoint just before the for loop, and stepped through each statement after it when I ran gdb on the "original version" of my program. But, I didn't make the connection between the fact it was comparing to ASCII, and therefore once it hit the space, that was causing the loop to stop before it got to the hash if it was more than 32 spaces from the start of the line. So yes, I did see what you're saying above about the space, and yes, I did print out the value of the array element it was up to, but like I said, I still wasn't making the connection - that's what I meant about not seeing anything that gave me any idea as to what astrogeek was talking about in post #2. But yes, I do get what you're saying now though. Thanks for your help.

Anyhow, and sorry phil.d.g, I think I may have gotten confused about what you were saying before, as I re-read your posts, and hopefully I get what you mean now. Although, I'm not sure if you meant "print the first character after any spaces for all of the lines in the file", or "print the first character after any spaces for just one line". So the code below will print out the first character after any spaces for all of the lines in the file. I tried again to try and get it to ignore anything with a hash before any characters bar any spaces, but not ignore the line if the hash isn't in front of any characters bar the space, and print out the whole line including what's after the hash, but on the same line, but I still couldn't figure it out. I managed to to everything but that though.

Anyway, here's the code as it stands now;

This is the "test file" as it is now;

And here's what the code above gives me when I run it;

No. You've got it. Well done.

So, what you've done is search for and print out the single character that is needed to make the decision "Is this line a comment or not", and then, for that line, stop looking at characters since we already have enough information.

I'm glad you've also attempted to move onto the next stage:

We're going to need this.

Your code and comments indicate that you do not fully understand what the break and continue keywords do.

Can I suggest reading the following:

https://www.tutorialspoint.com/cprog..._statement.htm
https://www.tutorialspoint.com/cprog..._statement.htm

And then have another attempt at figuring out where the commented out if statement I said we're going to need belongs.

1 members found this post helpful.

Thanks, I thought that's what you probably asking, but I still wasn't 100% sure I was thinking right.

I think you're right about the break and continue statements - I'm not sure the continue statement has ever been completely clear to me, beyond the obvious/the normal meaning of the word, as in: "keep doing it". I read the links you posted, but I think from memory that's the site I first started trying to follow when I first started trying to learn C, and then giving up on that same site because it just wasn't detailed enough, and the way it explains stuff was just too confusing and too brief for me to be able to properly understand the various concepts it talks about. I did find this site explaining the continue statement which seems at least a little clearer and easier to follow.

So to try and clear up any misunderstandings; does the break statement basically mean "stop and exit the loop or switch statement"? Does the continue statement (based on the link I posted above) basically mean instead of executing the following statements in the loop body, re-evaluate the loop condition? Beyond that, it really isn't clear to me.

Anyway, and back to the for loop; Based on what I think I understand about the break and continue statements, I cannot see how any of them fit into the if statement that runs if content[i] is not equal to a space. If I do need to use one of them, I'm honestly buggered if I know which one. I tried figuring out where I supposed to put the if statement you quoted above, and while I **think** it should be nested within the if statement that checks if content[i] is not equal to a space, I'm not 100% sure about that. Beyond that, I'm still pretty unclear on how to do what I was talking about before, and this is where I kept getting stuck before.

Then take them out and just use 'if's to achieve what you need.

Some folk actually hold the view that it's bad style to use break/continue at all. I don't agree as I think they have their place and are fine as long as you don't misuse them, but often you simply don't need break/continue.

1 members found this post helpful.

break = kicks it out of the loop. (switch too if using one).
continue = kicks it back to the condition, to loop again.

1 members found this post helpful.

Yes. And, it doesn't really need much more consideration than that. It doesn't matter how deeply nested the break or continue statements are, they still apply to the nearest outer for loop or switch statement. With the caveat they don't cross functions.

Have you tried this? Please do, and consider where it should belong relative to the break statement.

You can ignore the continue statement for now. That doesn't belong. I only wanted you to read about it because I saw you had it commented out.

1. What happens if you remove the break statement (no other changes) and run the program? Can you describe what has happened to the output? How is that different to the output generated when the break statement is present?
2. From the output you pasted in your last post, where you printed the first non space character of each line, is that enough information to determine whether or not each individual line is a comment or not?

Let's not worry about that for now. Just focus on the two questions above. The hardest part of programming, for me, is breaking down a problem into small, implementable steps, and then stringing those together to solve the big picture.

GazL has a point with respect to style. However, let's not worry about that for now. I'm trying to lead you to a solution using constructs and techniques you've previously demonstrated using. It's your solution, not mine. Worrying about style, efficiency, and even 100% correctness is a job for another day.

1 members found this post helpful.