Grr..

[ChefNinja]

OK, can someone point out what I am doing wrong here

This code executes fine until you define num at anything 1 million or greater. Anything lower and the code executes, at 1 million+ WinXP just gives me an error :\



#include <iostream.h>

#define NUM 1000000

void main()
{

long int array[NUM];

for (long int i=0; i <= NUM; i++){
array[i] = i;
}

for (long int x=0; x <= 100; x++){
cout << array[x] << "\n";
}

}

[kmj]

I just ran your code in linux and it seemed to work fine.

[kmj]

What error, exactly, does the compiler give you? C&P it if you can.

edit
/me is counting...
1 mississippi
2 mississippi
(can't post more than twice in 30 seconds!)
3 mississippi
...
30.

[gish]

does the compilor give you an error or the OS, in this case WINXP?....

G

[ChefNinja]

It's not a compiler error, the program compiles fine. I guess it's just WinXP... wow, thats great! :(


edit: I'm gonna have to load up linux on my 2nd hard drive again, maybe programming in linux will be a little more rewarding, eh? :)

[gish]

well i develop in WIN2000/WINXP I have XP at home so I will check it there to see if I can get teh same results as you....I will try it here in 2000 in a few mins.....

G

[gish]

yes...I got an error in win2000....just crashes.....no reason given..I will check the error log.....

[gish]

stack over flow........

[ChefNinja]

So uh, what should I do? :\

[CheeseLick]

The only thing I can see would be to change "\n" to endl. I'm not sure if it would make a difference, though.

From what I understand, endl flushes the output buffer. It might have something to do with that.

[Strike]

if just a million long integers overflows the stack ... that's kinda sad. long int's are 4 bytes on my system, so 1,000,002 long int's is not even 4MB of memory. And, unless I'm mistaken, the stack simply grows towards the heap (which grows down to the top of the stack), and together those two comprise all free memory in a system. Maybe Windows has some sort of setting that won't allow any given process allocate more than a certain amount of memory (4MB or less)? Maybe that is why threads are used so extensively ;)

[CheeseLick]

Yes. It's a long shot, but it might be worth it.

[strags]

You really shouldn't allocate such a large array on the stack. Yes, some OS's will allow you a massive stack, but some won't.

You're much better off dynamically allocating an array that size:

long *array=new long[NUM];

[PrBacterio]

long int array[NUM];
for (long int i=0; i <= NUM; i++){


ummm .... no wonder it crashes depending on random external conditions.

[CheeseLick]

Hot dog! We have a wiener!

[ChefNinja]

Thanks for your input guys :)

Strags, your suggestion seemed to fix the problem, thanks.

[stuka]

ChefNinja, if you don't pay attention to prBacterio's post, you're setting yourself up for problems. Notice the conditional in your loop: you use[code] i <= NUM [\code] Note that the maximum index for an array of size NUM is NUM - 1. WinXP is crashing because the system allocated just enough stack space for your array - trying to write to array[NUM] overflowed your stack. With the dynamically allocated version, you're overwriting the heap - hope you don't have anything else there....

[ChefNinja]

OOooh I see now

[assembler-robot]

So it would be better to say i <= (NUM-1)? Sorry, just trying to understand here

[PrBacterio]

Originally posted by assembler-robot
So it would be better to say i <= (NUM-1)? Sorry, just trying to understand here
Nothing to apologize for. And, yes. Though I usually write it as "i < NUM" but that is purely a matter of taste.
The loop only terminates when the condition is not met anymore, and by the time "i <= NUM" is false, i is already equal to NUM + 1 and the loop's body has already been executed once with i == NUM; the array's fields, though, are numbered 0 through NUM - 1 (inclusively).