Thread: Copying memory, pointers and the like.

I'm not so sure it is that bad. I'm also not sure if you are understanding what we are saying. It shouldn't be that difficult to find the problem if you can follow the advice here. If the location of the trhead is 00000000, then you might simply be trying to execute a member function from a null pointer.

Look at this code. Create an empty project and run it. Where does it fail? Do you get the same type of error?

Code:

#include <iostream>
#include <vector>
#include <cstddef>

class One
{
public:
    One() { vec.push_back(19); }
    std::vector<int> vec;
};

class Two
{
public:
    Two() { ptr_to_one = NULL; }
    One* ptr_to_one;
};

int main()
{
    Two* ptr_to_two = NULL;
    std::cout << ptr_to_two->ptr_to_one->vec[0];
}

What you need to do is find out where the null or invalid pointer is. Answering the questions and trying the things we've suggested should help you do that.

>> I don't see any sign of an invalid pointer, unless i'm still missing something.
You have to look further down the call stack. When you are at the point of the error, open the Call Stack window (or tab or whatever you can find in VC++ that has the Call stack). It should have the list of functions that have been called starting from main and going up to the current function. Start at the second one from the top if you recognize the function. If it is some vector function or some other class that you did not write, go down until you find the first function name you recognize. Double-click on that line and it will bring you to the function. You will be able to look at the variables in that scope. For example, if you change your code to this:

Code:

SubClass* subclass = data->subclass;
std::vector<OtherVectorClass*> vec = subclass->vector;
OtherVectorClass* ovc = vec[data->var];
ovc->AddToVector();

Now, when the error occurs, and you go to this place in the call stack, you can look at data, subclass, vec and ovc separately to see which if any have corrupted data. The first one (from top to bottom) to be bad is the one that you want to concentrate on. You can also verify that vec.size() is 1 and that data->var is 0.

This doesn't guarantee that you will find the problem, but that's how you need to break it down.

>> Again, sorry for my faliure to comprehend here.
No worries. The VC++ debugger is a powerful tool but it takes a while to get used to. Once you get familiar with its features it will really help speed up the time it takes to find bugs like this, especially when the bug is created in a different part of the code than it shows up in.