what is the order of FOR command

i got

Code:

---

for(k=0;k<10;k++)

---

what is the order:
does it checks if k<10 and the does k++
or the opposite
??

It does the things in the order you specify them (sort of): initialize, then check condition, then the contents of the loop, then update the iterator, then check the condition and the next iteration of the loop, etc.

Obviously, if the condition is false when it's checked, nothing else is done - the loop ends.

--
Mats

How about adding a printf statement to print out the value of k every loop and find out for yourself?

so when the loop ends the value of K is 10
?

It checks the condition first. That means with your example, the loop will run while k is 0-9, but after the last loop is done, k will equal 10.

How about adding a printf statement to print out the value of k every loop and find out for yourself?

thanks

Quote:

---

Originally Posted by Adak

How about adding a printf statement to print out the value of k every loop and find out for yourself?

---

How about using a debugger to find out?

It might help to compare your loop with an equivalent while loop:

Code:

---

/* for(k=0;k<10;k++) */
k = 0;

while ( k < 10 ) {
  /* Body of the loop */
  k++;
}

---

The for construct can be confusing at first.

Quote:

---

Originally Posted by Elysia

How about using a debugger to find out?

---

Isn't that kind of like driving to your neighbour's when you live in row housing?

No, it's not.
It's probably the best way of understanding things.
Printf-crap & co is overkill.

I personally think both debugger and printf are good tools for this particular problem - either will solve it. One requires changes to the code, the other knowledge of a debugger. Knowing how to use a debugger is really useful!

--
Mats

Quote:

---

Originally Posted by Prelude

It might help to compare your loop with an equivalent while loop:

Code:

---

/* for(k=0;k<10;k++) */
k = 0;

while ( k < 10 ) {
  /* Body of the loop */
  k++;
}

---

The for construct can be confusing at first.

---

This would be the first logical step for those learning the ropes imho before diving into debugging which leads to more advanced skills.

Learning how to use a debugger is the first thing you should do after learning how to compile.
It will save hours of headaches.
And is a super-easy debugger to use for Windows called Visual Studio. It's so easy that pretty much anyone can use it with basic knowledge of debugging (ie, what is step in, step out and step over).

Quote:

---

Originally Posted by Elysia

No, it's not.
It's probably the best way of understanding things.
Printf-crap & co is overkill.

---

Wow, I am surprised to read this, but then the only debugger I've tried is gdb.

I was actually thinking of starting a poll (are there polls at cboard?) to find out what people's favourite method of debugging is because mine is definitely

printf

and even

puts("You made it this far...");

which perhaps demonstrates that I could really use a poll of other people's opinions to help me consider more fulfilling alternatives ;)

>Wow, I am surprised to read this
Debugging methods are a matter of opinion, it's as simple as that. A good debugger is often a critical tool, but debugging output has it's place as well. It's usually the first method you learn, and you'll use it regularly.

printf() is like triage. Debugging is like a diagnosis.

Quote:

---

Originally Posted by MK27

Wow, I am surprised to read this, but then the only debugger I've tried is gdb.

I was actually thinking of starting a poll (are there polls at cboard?) to find out what people's favourite method of debugging is because mine is definitely

printf

and even

puts("You made it this far...");

which perhaps demonstrates that I could really use a poll of other people's opinions to help me consider more fulfilling alternatives ;)

---

Those are pretty useless output statements.
A debugger will give you that and, oh so much more.
Not to say it does not have its place, as Prelude suggests, however. It does.
But what you use it for is not one of them.

Yuck printf debugging!
Since I learned about the "When hit" option of breakpoints in Visual Studio, I don't recall ever inserting tracing code to debug ever again.