Getting to learn about arrays but have problem

[ClientAlive]

How do you get rid of the junk from in memory? That's something I've been wondering about for a while now.

[ClientAlive]

Any idea to print one less entry? Look at your loop!

Well that's odd. Yes, removing the equals sign from the loop with the printf statement in it does make it loop one less time - except when I followed the ttl and i varibles through in my mind I came up with the right numbers. If a user had entered 5 ttl would be 5, i would stop at 4 so it would go 0, 1, 2, 3, 4 and the loop with the prinf at the end would stop at <= i so it would stop at 4 also and would go 0, 1, 2, 3, 4 just. Seemed like all the right numbers the way it was. But I removed the equals sign, recompiled and ran it and it works like it should now. Hmmm. Gave it a sentinel number though

#include <stdio.h>

int main (void)

{
int x, i, j, ttl;

do
	{
	printf("How many numbers will you be entering today (enter -99
        to exit)? \n");
	scanf("%i", &ttl);

	int num[ttl];

		if(ttl > 0 && ttl != -99)
			{
			for(i=0; i<ttl; ++i)
				{
					printf("Enter a number: \n");
					scanf("%i", &num[i]);
				}

			printf("The numbers you entered are: \n");
			
			for(j=0; j<i; ++j)
				{
				printf("%d\n", num[j]);
				}
			}
	}
while(ttl != -99);
return 0;
}

-------------------

Edit:

Oh wow! I think I was getting confused because i was ending on 4 (assuming you pick the number 5 to trace it out). 0, 1, 2, 3, 4 is still 5 times around so when i would get to my j loop it would be 5 even though it ended on 4 in the previous loop. right? If that's what's going on behind the scenes here that just seems odd.
-------------------

Edit:

If that's what's going on then it must mean there are really two diff sets of numbers going on here. There's the number the varible starts on and ends on and everything in between, there's that set of numbers, then there's the quantity of times (two different things). If that's right, and a guy didn't figure that out, it could give you all kind of grief trying to get it right. What a trip!

[Bachstelze]

It does not "stop on 4". It stops when the condition i<5 stops being true, i.e. when i becomes 5. This happens between the 5th and 6th iterations of the loop. You do not seem to understand how for loops work, so how about reading up on that instead of writing code you do not understnad yourself?

[ClientAlive]

It does not "stop on 4". It stops when the condition i<5 stops being true, i.e. when i becomes 5. This happens between the 5th and 6th iterations of the loop. You do not seem to understand how for loops work, so how about reading up on that instead of writing code you do not understnad yourself?

So you advise that I stop writing code?

Or is the problem just that I don't know everything in advamce of learning it?

[Bachstelze]

So you advise that I stop writing code?

Or is the problem just that I don't know everything in advamce of learning it?

Writing code at random is not a good way to learn, as you should have guessed by now. You don't start working on car engines before you have at least a basic understanding about their internal structure and are able to tell which part does what and when. Same thing for C loops, especially for loops. They have four different parts, and before you start working with them, you should have a basic understanding of which part does what and when. And you can only get to know this by reading up on it, not by throwing various things at it and try to guess how it works.

[ClientAlive]

#include <stdio.h>

int main (void)

{
	
int i, j, k;

	for(i=0; i<5; ++i)
		{
		printf("for(i=0; i<5; ++i)\n");
		printf("The value of i is %i\n", i);
		}
		
/*The output shows the last value of i to be 4. This is deceptive because it really
is only the last time the printf statement executed. The counter increments after
the body of the loop is executed so the value of i will be increased one last time
but will not be printed to the screen. I assume that, after the counter increases
the value of i that last time, the program does yet one more thing - it reads the
for conditions again. (This is called the scientific method: hypothesis, conduct
experiment, evaluate results and compare, repeat). It is at that time that it finds
the statemtent to be untrue (this is called the hypothesis). It is at that time that
it does not execute again because the conditions are found to be no longer true -
et, because it does not execute that last time it does not print the final value of
to the screen. To discover what that final value is FROM WRITING AND EXECUTING CODE
we must add the additional for loops below that are tied to the value of the
variable in the first for loop.*/
	 
	for(j=0; j<=i; ++j)
		{
		printf("for(j=0; j<=i; ++j)\n");
		printf("The value of j is %i\n", j);
		}
		
/*The output shows the last number printed is 5. But the last number printed is
based on the 'actual' last value of i (a final value which was not reflected in the
output from the for loop in i) from our first for foop this shows that the variable
in a for loop is increased one last time after the for loop stops executing. (it is
throught the addition of this loop that the hypothesis is tested and proved).*/
		
	for(k=0; k<=j; ++k)
		{
		printf("for(k=0; k<=j; ++k)\n");
		printf("The value of k is %i\n", k);
		}
		
/*The output shows the last number printed is 6. But the last number printed is
based on the 'actual' value of j from our second for loop, which is in turn based on
the 'actual' value of i before it. This proves definitively that the variable in a
for loop is increased one last time after the for loop stops executing  --(not
because someone else gave you their way of understanding how a for loop works but
because the program itself told you what it is doing, how it is doing it, what order
it's doing it in). (It is through the addition of these two loops that deductive
proof is formed). But don't rely on my SUBJECTIVE WAY OF UNDERSTANDING AND
DESCRIBING HOW IT WORKS - look at the output and compare it with the code yourself.*/
		
return 0;
}

[muteXe]

OP, have a little read of this: http://en.wikipedia.org/wiki/Off-by-one_error .

And I agree with Bachstelze. If you ever write code that don't understand, stop and make an effort to understand. And just because it compiles doesn't make it correct.

[ofnuts]

.

[ClientAlive]

there are few problems with your program, i slightly modified the printf line to contain both num[] and &num[]

for(j=0; j<=i; ++j)
  printf("%i %i\n", &num[j], num[j] );

output:

How many numbers will you be entering today? 
2
Enter a number: 
1
Enter a number: 
2
The numbers you entered are: 
517633760 1
517633764 2
517633768 391983400

as it stands, there will be one iteration too many. For i=2 j={0,1,2}
that additional iteration will produce garbage, you reach to a memory that is not a part of the array.
Also note the difference between &num[j] and num[j] - num[j] is an integer, no problems here, but look what happens with & (it means 'location in memory of the stuff that is right after', in other words 'pointer to'). You print out memory address in an integer form.

Vaphell, you tried to show me what was going on but I didn't see it at first. It wasn't until I ran some tests and then saw this again that I realized you'd shown me the difference between what you get with the & sign in a statment like that and without it. My bad, man. Sorry I missed it the first time.

[Bachstelze]

"I assume", "I assume", "I assume".

NO. You should never "assume" anything. You should read a good source on C and find out exactly how things work. Your pseudo-scientific method of trying random things until you get something that looks like it could possibly be how things work might work on something as simple as this but will fail miserably on more subtle aspects of the language.