• Create Account

### #Actualstitchs

Posted 20 July 2012 - 12:35 PM

I am by no means an expert on debugging, nor am I saying "How do you not know debugging!!!!" as, trust me, I too was once in your shoes.

Once you understand that debugging shows you what your variables ACTUALLY contain, or which memory address is ACTUALLY being pointed too, as opposed to what you think is happening, you will learn more about coding than hacking away at previous functions that may, or may not, work as to how you expect.

The main thing I can say is that it is great at helping you identify a point in your code where you may have forgotten to initialise an attribute/variable or a pointer with a default value. This may sound like a silly thing in a program slightly bigger than your basic "Hello World" but when it come to multiple classes throwing data at each other, you might have a check in one class for an integer value of 0 - 5, but the class that supplies this data hasn't been initialised at all, so it will never compare and execute when you want.

E.g.

class A{
void method_A(int paramA)
{
if(paramA >= 0 && paramA <= 5)
{
//execute one
}
else if(paramA > 5)
{
//execute another
}
}
}
main(){
int test;
A();
A.method_A(test);


This may lead to undesired results. This would be easy to spot for such a short program, but imagine having lines and lines of code where you might be unable to spot such a silly error, using the Debugger will allow you to put a break point in the code. This will halt execution at the point of break. If you break when the Integer 'test' is first declared, and step over it, you will see in your locals window that it will represent the value -854637382 (I cannot remember the number exactly, but its the maximum negative value for said data type). From that, you will know that 'test' was never initialised, and the method of Class A will never run as expected.

This is the simplest way I can show you the benefits of using a debugger. If anyone with more experience thinks this incorrect, then I do apologise if I have given an incorrect explanation, or my example isn't up to scratch.

With regards to your original question, I had a similar problem, and I will look for the program that I personally overcame it in. When I do find it, I will post here with an explanation of where I went wrong, and how it can be applied to your issue.

Regards,

Stitchs.

### #2stitchs

Posted 20 July 2012 - 12:33 PM

I am by no means an expert on debugging, nor am I saying "How do you not know debugging!!!!" as, trust me, I too was once in your shoes.

Once you understand that debugging shows you what your variables ACTUALLY contain, or which memory address is ACTUALLY being pointed too, as opposed to what you think is happening, you will learn more about coding than hacking away at previous functions that may, or may not, work as to how you expect.

The main thing I can say is that it is great at helping you identify a point in your code where you may have forgotten to initialise an attribute/variable or a pointer with a default value. This may sound like a silly thing in a program slightly bigger than your basic "Hello World" but when it come to multiple classes throwing data at each other, you might have a check in one class for an integer value of 0 - 5, but the class that supplies this data hasn't been initialised at all, so it will never compare and execute when you want.

E.g.
[source lang="cpp"]class A{void method_A(int paramA){ if(paramA >= 0 && paramA <= 5) { //execute one } else if(paramA > 5) { //execute another }}}main(){ int test; A(); A.method_A(test);}[/source]
This may lead to undesired results. This would be easy to spot for such a short program, but imagine having lines and lines of code where you might be unable to spot such a silly error, using the Debugger will allow you to put a break point in the code. This will halt execution at the point of break. If you break when the Integer 'test' is first declared, and step over it, you will see in your locals window that it will represent the value -854637382 (I cannot remember the number exactly, but its the maximum negative value for said data type). From that, you will know that 'test' was never initialised, and the method of Class A will never run as expected.

This is the simplest way I can show you the benefits of using a debugger. If anyone with more experience thinks this incorrect, then I do apologise if I have given an incorrect explanation, or my example isn't up to scratch.

With regards to your original question, I had a similar problem, and I will look for the program that I personally overcame it in. When I do find it, I will post here with an explanation of where I went wrong, and how it can be applied to your issue.

Regards,

Stitchs.

### #1stitchs

Posted 20 July 2012 - 12:30 PM

I am by no means an expert on debugging, nor am I saying "How do you not know debugging!!!!" as, trust me, I too was once in your shoes.

Once you understand that debugging shows you what your variables ACTUALLY contain, or which memory address is ACTUALLY being pointed too, as opposed to what you think is happening, you will learn more about coding than hacking away at previous functions that may, or may not, work as to how you expect.

The main thing I can say is that it is great at helping you identify a point in your code where you may have forgotten to initialise an attribute/variable or a pointer with a default value. This may sound like a silly thing in a program slightly bigger than your basic "Hello World" but when it come to multiple classes throwing data at each other, you might have a check in one class for an integer value of 0 - 5, but the class that supplies this data hasn't been initialised at all, so it will never compare and execute when you want.

E.g.
[source lang="cpp"]class A{void method_A(int param){ if(param >= 0 && param <= 5){ // execute one statement } else if(param > 5){ // execute another statement } }}main(){ int test; A(); A.method_A(test);}[/source]
This may lead to undesired results. This would be easy to spot for such a short program, but imagine having lines and lines of code where you might be unable to spot such a silly error, using the Debugger will allow you to put a break point in the code. This will halt execution at the point of break. If you break when the Integer 'test' is first declared, and step over it, you will see in your locals window that it will represent the value -854637382 (I cannot remember the number exactly, but its the maximum negative value for said data type). From that, you will know that 'test' was never initialised, and the method of Class A will never run as expected.

This is the simplest way I can show you the benefits of using a debugger. If anyone with more experience thinks this incorrect, then I do apologise if I have given an incorrect explanation, or my example isn't up to scratch.

With regards to your original question, I had a similar problem, and I will look for the program that I personally overcame it in. When I do find it, I will post here with an explanation of where I went wrong, and how it can be applied to your issue.

Regards,

Stitchs.

PARTNERS