Hey there, this problem has been bugging me all day. I'm currently attempting to write some code that will (in theory) record track lengths of a particle going through nested cylindrical volumes (beginning with the smallest and working outward). I have a vertex position fixed at (0,0,0) to make the canned tests easier to verify and I'm looping over forward angles (0 to 90 degrees) and radial angles (0 to 359 degrees). The main function is shown below:
int main(){
int p = 0;
int n = 0;
float a = 0;
float b = 0;
float c = 0;
float vert[] = {0, 0, 0};
for (n=0;n<=90;n++){
for (p=0;p<=359;p++){
float ang1 = (n*2*pi)/360;
float ang2 = (p*2*pi)/360;
float t1 = tan(ang1);
float t2 = tan(ang2);
c = sqrt(1/(1+pow(t1,2)));
a = t1*sqrt(1/((1+pow(t2,2))*(1+pow(t1,2))));
b = t2*t1*sqrt(1/((1+pow(t2,2))*(1+pow(t1,2))));
float dir[] = {a, b, c}; cout << a << ", " << b << ", " << c << endl;
FROST(vert, dir);
cout << p << " = " << length[0] << endl;
}
}
My two sub-routines are ones for determining the intercept and one to determine how far in each cylinder the track goes. The issue I'm having is when I comment out the bold statement it gives me garbage, but when I leave it in I get the correct results for all angles. I'm really at a loss for why this would happen since everything I've read is telling me that a cout shouldn't be altering a variable's value. I've tried placing the cout before and after the FROST function call and it only causes the results to be correct when placed before. I've verified that if I only input single fixed directionals the other two functions appear to work correctly, but I still need to iterate over all angles to be sure. Anyone able to give some insight as to why this is happening? Thanks in advance.
Sounds like classic memory corruption. Odds are you are stepping out of bounds of an array somewhere, corrupting memory when you do so.
cout has nothing to do with it, the additional code just rearranges where everything gets put on the heap, so you end up corrupting different memory, which causes the bug to be difficult to reproduce.
I can't see any corruption in the code you posted... about the only thing that stands out is this:
1 2
for (n=0;n<=90;n++){ // <--- <= 90 ?? did you mean < 90 ?
for (p=0;p<=359;p++){
If that's not it, then I don't have any other input for you. Double check all your loop ranges to make sure you're not iterating one too many times ... make sure all your arrays are large enough -- maybe try increasing all of their sizes until the bug corrects itself to isolate the culprit, then look at how you're indexing that array to make sure you're not stepping outside of it.
Heap corruption is a beast. Worst kind of bug out there. =(
Good luck.
Thanks for the quick response. Sounds like I'm in for a "fun" afternoon. In regards to the 90, I do intend to use that since that will be the situation where the track starts at (0,0,0) and goes out entirely in the x-y plane. I'll look through all my loops again and check each array index.
edit:
Its all working now, got rid of all the floats and used doubles instead and cleaned up things in a few spots. Thanks again for the help guys!