-
function loading problem
I load a function from main.cpp. It includes a file where the function is.
The functions header is:
Code:
void my_function(int buff[], int length)
I make this call from main.cpp:
Code:
my_function(buff[2], length);
buff[2] is an array which contains 0 and 1. length's value is 2.
When I debug the values are correct, but immediately after loading the function, they turn into different values right after function call. It seems that it doesn't have anything wrong with code, the function doesn't even change these values, it only uses them in calculations.
-
I believe you could change:
Code:
void my_function(int buff[], int length)
my_function(buff[2], length);
to
Code:
void my_function(int *buff, int length)
my_function(buff, length);
-
Sorry, I gave you some wrong information.
The call I use is:
Code:
int length=2;
int buff[2]={0, 1};
my_function(buff, length);
I mean I throw the whole buffer into function. Is it allowed? It worked under a bit different conditions and I fear it might give unstable results.
-
Yes, it works. And...
Code:
void my_function(int buff[], int length);
...and...
Code:
void my_function(int* buff, int length);
Are exactly the same thing.
But this is C++, so it's better if you were to use std::vector instead.
-
But why do I get such results when debugging? There's no way in code that would change those variables.
-
I can't say. It must depend on HOW you're debugging it, because the code is correct.
Although you may want to note that the array is an array no longer when passed to the function. In that function, it's a pointer, regardless of syntax.
And that means you can only see the first value, unless you manually tell the debugger to print the value of buff[0] and buff[1]. Perhaps that's the problem.
-
Cause (where the bug really is) and effect (where you happen to notice something is wrong) are seldom in the same place when it comes to more complicated programs.
You can post all the snippets of where the effect is, but that won't tell us anything. All we'll be able to tell you is there's nothing wrong with that bit of code. If you copied the same code into an empty project and just called it, you'd see that too.
The ideal scenario (for you) is being able to produce a cut down copy of the program (to a few hundred lines) which demonstrates the problem, which you can then post as a complete program. We could probably figure something out from that.
If it's thousands of lines long, then you're pretty much on your own. Going through all the code run up to that point in detail, considering any potential for corrupted memory as you go.
It's one of those "rites of passage" things on the way to becoming an experienced programmer. Avoiding such problems in the first place, and knowing how to go about solving them if they do show up.