Learn from my fail: check your pointers
I spent quite some time tracking down an issue I was having with my C++ project. Here is a snippet of the code:
class foo { private: bool* myArray; public: foo() { myArray = new bool[5]; for(int i=0; i<5; i++) { myArray = false; } } void init() { myArray[0] = true; } };
Every time I ran it, it would throw a memory access violation. I was very puzzled by this since it was just a standard boolean array holding true or false. It wasn’t anything very advanced. I used the Visual Studio debugger to poke around. It goes through the constructor fine and then when it goes into the init()
function myArray
would become a null pointer. The debugger would report that myArray
has a memory address of 0x00000000.
I was very confused because how could the pointer be initialized properly in the constructor, but not be initialized when I step into another function in the same object? I chased it all afternoon and decided to give up and walk away. The next morning, I looked at the code again. Then it hit me: the problem and solution was staring at me in the face.
In the for
loop in the constructor I have this code:
myArray = false;
I had forgotten to put in the array subscript! If myArray
was a true null pointer, it would have just said it was uninitialized or “nullptr” with a stop icon instead of a zero memory location. What was happening was that the pointer was being set to false
, which is zero. That is why the debugger showed that the memory location was 0x00000000. So when I access the pointer to assign a value, I am accessing memory that is already reserved or in-use so it throws a memory access violation. The code is “valid” which is why it doesn’t show any errors during compilation, but it doesn’t produce the desired results at runtime.
With the correct code:
myArray[i] = false;
Everything works fine and I was able to continue my project! After working with C# for a while, it’s an eye opener how much the .Net garbage collector and managed heap does for the programmer.