Reminds me of the days before ai assistants where people copy pasted code from forums and then you’d get quesitions like “I found this code and I know what every line does except this ‘for( int i = 0; i < 10; i ++)’ part. Is this someone using an unsupported expression?”
It’s a standard formatted for-loop. It’s creating the integer variable i, and setting it to zero. The second part is saying “do this while i is less than 10”, and the last part is saying what to do after the loop runs once -‐ increment i by 1. Under this would be the actual stuff you want to be doing in that loop. Assuming nothing in the rest of the code is manipulating i, it’ll do this 10 times and then move on
I would also add that usually i will be used inside the code block to index locations within whatever data structures need to be accessed. Keeping track of how many times the loop has run has more utility than just making sure something is repeated 10 times.
@Moredekai@lemmy.world posted a detailed explanation of what it’s doing, but just to chime in that it’s an extremely basic part of programming. Probably a first week of class if not first day of class thing that would be taught. I haven’t done anything that could be considered programming since 2002 and took my first class as an elective in high school in 2000 but still recognize it.
This reads as “assign an integer to the variable I and put a 0 in that spot. Do the following code, and once completed add 1 to I. Repeat until I reaches 10.”
Int I = 0 initiates I, tells the compiler it’s an integer (whole number) and assigns 0 to it all at once.
I ++ can be written a few ways, but they all say “add 1 to I”
I < 10 tells it to stop at 10
For tells it to loop, and starts a block which is what will actually be looping
I mean i < 10 isn’t wrong as such, it’s just good practice to always use <= because in the INT_MAX case you have to and everything should be regular because principle of least astonishment: That 10 might become a #define FOO 10, that then might become #define FOO INT_MAX, each of those changes look valid in isolation but if there’s only a single i < FOO in your codebase you introduced a bug by spooky action at a distance. (overflow on int is undefined behaviour in C, in case anyone is wondering what the bug is).
…never believe anyone who says “C is a simple language”. Their code is shoddy and full of bugs and they should be forced to write Rust for their own good.
But your case is wrong anyways because i <= INT_MAX will always be true, by definition. By your argument < is actually better because it is consistent from < 0 to iterate 0 times to < INT_MAX to iterate the maximum number of times. INT_MAX + 1 is the problem, not < which is the standard to write for loops and the standard for a reason.
You’re right, that’s what I get for not having written a line of C in what 15 years. Bonus challenge: write foriini32::MIN..=i32::MAX in C, that is, iterate over the whole range, start and end inclusive.
(I guess the ..= might be where my confusion came from because Rust’s .. is end-exclusive and thus like <, but also not what you want because i32::MAX + 1 panics).
Would you be bold enough to write if (i++ == INT_MAX) break? The result of the increment is never used, but an increment is being done, at least syntactically, and it overflows, at least theoretically, so maybe (I’m not 100% sure) the compiler could be allowed to break out into song because undefined behaviour allows anything to happen.
Reminds me of the days before ai assistants where people copy pasted code from forums and then you’d get quesitions like “I found this code and I know what every line does except this ‘for( int i = 0; i < 10; i ++)’ part. Is this someone using an unsupported expression?”
I’m less knowledgeable than the OOP about this. What’s the code you quoted do?
It’s a standard formatted for-loop. It’s creating the integer variable i, and setting it to zero. The second part is saying “do this while i is less than 10”, and the last part is saying what to do after the loop runs once -‐ increment i by 1. Under this would be the actual stuff you want to be doing in that loop. Assuming nothing in the rest of the code is manipulating i, it’ll do this 10 times and then move on
I would also add that usually i will be used inside the code block to index locations within whatever data structures need to be accessed. Keeping track of how many times the loop has run has more utility than just making sure something is repeated 10 times.
It’s a for loop. Super basic code structure.
@Moredekai@lemmy.world posted a detailed explanation of what it’s doing, but just to chime in that it’s an extremely basic part of programming. Probably a first week of class if not first day of class thing that would be taught. I haven’t done anything that could be considered programming since 2002 and took my first class as an elective in high school in 2000 but still recognize it.
for( int i = 0; i < 10; i ++)This reads as “assign an integer to the variable
Iand put a 0 in that spot. Do the following code, and once completed add 1 toI. Repeat untilIreaches 10.”Int
I= 0 initiatesI, tells the compiler it’s an integer (whole number) and assigns 0 to it all at once.I++ can be written a few ways, but they all say “add 1 to I”I< 10 tells it to stop at 10For tells it to loop, and starts a block which is what will actually be looping
Edits: A couple of clarifications
i <= 9, you heathen. Next thing you’ll do isi < INT_MAX + 1and then the shit’s steaming.I’m cooked, see thread.
<=makes sense if you start from 1.If it was correct it wouldn’t have been copied into the forums lmao
I mean
i < 10isn’t wrong as such, it’s just good practice to always use<=because in theINT_MAXcase you have to and everything should be regular because principle of least astonishment: That10might become a#define FOO 10, that then might become#define FOO INT_MAX, each of those changes look valid in isolation but if there’s only a singlei < FOOin your codebase you introduced a bug by spooky action at a distance. (overflow on int is undefined behaviour in C, in case anyone is wondering what the bug is).…never believe anyone who says “C is a simple language”. Their code is shoddy and full of bugs and they should be forced to write Rust for their own good.
But your case is wrong anyways because
i <= INT_MAXwill always be true, by definition. By your argument<is actually better because it is consistent from< 0to iterate 0 times to< INT_MAXto iterate the maximum number of times.INT_MAX + 1is the problem, not<which is the standard to write for loops and the standard for a reason.You’re right, that’s what I get for not having written a line of C in what 15 years. Bonus challenge: write
for i in i32::MIN..=i32::MAXin C, that is, iterate over the whole range, start and end inclusive.(I guess the
..=might be where my confusion came from because Rust’s..is end-exclusive and thus like<, but also not what you want becausei32::MAX + 1panics).for (int i = INT_MIN; ; i++) { ... if (i == INT_MAX) break;}Would you be bold enough to write
if (i++ == INT_MAX) break? The result of the increment is never used, but an increment is being done, at least syntactically, and it overflows, at least theoretically, so maybe (I’m not 100% sure) the compiler could be allowed to break out into song because undefined behaviour allows anything to happen.