The problom was abcde::iInt1 [1] somtimes it would equel 0, wich realy upsets the %.
I was right.
That took me months (litreley).
Thx for all the help :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-08-19
Yes, should have spotted that (hangs head in shame), n % 0 causes a divide by zero error.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-08-18
That code on its own would not produce that output. It would not on its own compile. You will probably need ot post more than just a fragment. Ideally enough to reproduce the error elsewhere. Improtantly it includes no information about the types and sizes of any of the arrays involved.
Since the last think it output was "4", and that was the last 'debug; line you placed the crash may have occurred at at time thereafter. The root cause of the the crash however may have occurred anywhere - which is why your 'guess; at the location is flawed.
It is not the cause of your problem but is 'nasty' code nonetheless, but in the line:
abcde::iInt1 [4] = abcde::iInt1 [1] * 0.5;
I am assuming that iInt is an array of integers, the use of mixed types in the assignment expression is unnecessary and inefficient; prefer:
abcde::iInt1 [4] = abcde::iInt1 [1] / 2 ;
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i put the abcde::iInt1 [3] and the abcde::iInt1 [4] in becouse that caused t
he same windows error i typed above, sooo... its still the that line... can any1 tell me if it is modulus? i don't know that much about modulus.
theres another thing too, i included the "entering 1 1 1 2 3 4 leaving" part of the progam output becuase its strange, abcde::iInt1 [2] shouden't change in the whole section, as there are no dunction calls to functions defined in my progam, and its namespaced, so no functions oustside it should be able to change it (thats why its namespaced), so the " 2 3 4 " should print the amount of " 1 "s of progam output - 1, but it doesen't it allways prints at the end however many times i run that segment of code.
oh and the code was never meant to read by any1 but me, so its not that neat.
wow... i'm realy bad at typing and writing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-08-19
It seems likely to me that the variable "Options" has been corrupted and no longer points to the original array, but to an invlaid location - the consequent dereference causes the program to crash.
Either use the debugger (but it sucks) or add the following just after cout<<" 4 ";
printf( "Options=%p\n", Options ) ;
I know it uses <stdio.h>, but there are some things that the C library is just better for, and debug output is one of them - especially printing pointer values - it gets tedious in <iostream>.
If the value changes, your mission is to find out why and where - good luck!
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Code with bug in (i think):
Progam output:
...entering 1 1 1 2 3 4 leaving entering 1 1 2 3 4
And I get from windows:
Ai has caused an error in AI.EXE.
Ai will now close.
If you continue to experience problems,
try restarting you coputer.
I'm using dev c++ 4.9.9.2 on windows me, i'm pretty sure both are up to date.
Fixed it
The problom was abcde::iInt1 [1] somtimes it would equel 0, wich realy upsets the %.
I was right.
That took me months (litreley).
Thx for all the help :)
Yes, should have spotted that (hangs head in shame), n % 0 causes a divide by zero error.
Clifford
That code on its own would not produce that output. It would not on its own compile. You will probably need ot post more than just a fragment. Ideally enough to reproduce the error elsewhere. Improtantly it includes no information about the types and sizes of any of the arrays involved.
Since the last think it output was "4", and that was the last 'debug; line you placed the crash may have occurred at at time thereafter. The root cause of the the crash however may have occurred anywhere - which is why your 'guess; at the location is flawed.
It is not the cause of your problem but is 'nasty' code nonetheless, but in the line:
abcde::iInt1 [4] = abcde::iInt1 [1] * 0.5;
I am assuming that iInt is an array of integers, the use of mixed types in the assignment expression is unnecessary and inefficient; prefer:
abcde::iInt1 [4] = abcde::iInt1 [1] / 2 ;
Clifford
sorry, this is my first time posting on a fourem, so i diden't know how much information to post,
I'll post explanations for lots of things.
these are the variable definitions:
int abcde::iInt1 [5] = {0, 0, 0, 0, 0};
short Options [9] = {0, 0, 0, 0, 0, 0, 0, 0, 0};
unsigned short TurnsPast = 0;
functions:
rand () is the rand () from stdlibb
cout is from iostream, i've put using namespace std; at the top of my source file
and the ... at the begging of the input is just there because thers loads of output before that, wich i diden't see any point in including.
how can the root cause of the crash be anywhere bewteen the 4 and leaving debug outputs?
the line there has no functions.
my only guess is the modulus.
Options [abcde::iInt1 [0]] += abcde::iInt1 [3] % abcde::iInt1 [4];
orginly, it was:
Options [abcde::iInt1 [0]] += rand() % abcde::iInt1 [1] * 0.5;;
i put the abcde::iInt1 [3] and the abcde::iInt1 [4] in becouse that caused t
he same windows error i typed above, sooo... its still the that line... can any1 tell me if it is modulus? i don't know that much about modulus.
theres another thing too, i included the "entering 1 1 1 2 3 4 leaving" part of the progam output becuase its strange, abcde::iInt1 [2] shouden't change in the whole section, as there are no dunction calls to functions defined in my progam, and its namespaced, so no functions oustside it should be able to change it (thats why its namespaced), so the " 2 3 4 " should print the amount of " 1 "s of progam output - 1, but it doesen't it allways prints at the end however many times i run that segment of code.
oh and the code was never meant to read by any1 but me, so its not that neat.
wow... i'm realy bad at typing and writing.
It seems likely to me that the variable "Options" has been corrupted and no longer points to the original array, but to an invlaid location - the consequent dereference causes the program to crash.
Either use the debugger (but it sucks) or add the following just after cout<<" 4 ";
printf( "Options=%p\n", Options ) ;
I know it uses <stdio.h>, but there are some things that the C library is just better for, and debug output is one of them - especially printing pointer values - it gets tedious in <iostream>.
If the value changes, your mission is to find out why and where - good luck!
Clifford
...entering 1 1 1 2 3 4 Options=0066F620 leaving entering 1 1 2 3 4 Options=0066F620
Same address, so if it was fatal it would have died the first time. In any case Options is used in a number of other places.