I've tried my best to maintain the essence of what the code is doing in my example. I know you're thinking, the answer must be in something he's doing in the REAL code that's not represented in this example. But it's really not. I'm not uploading the exact code because it's just too big. I realize that's not helpful. Try to focus on the fact that moving the green line ahead of the red line fixes the problem. Because that part of the example is exactly the same as the source, minus some name changing.
Your basic example is incomplete. Most likely you are using the global gpObj variable in one of the Init functions, and the Init functions are called before you assign a valid pointer to gpObj...
Nothing even sort of close to that is happening. But specifically, I can assure you, the global pointer is not referenced in any way in a.Init() or by anything it calls (it actually doesn't call anything). It really is as benign as assigning a literal value to member data.
I'm confused how this is even compiling, due to this:
class Object
{
int data[10];
};
Class members are _private_ by default. That means that derived classes will not be able to access these members. You will need to declare the `data` member in a protected or public access level for `A` to have access to it.
--
The runtime error makes no sense. This probably isn't the actual code you're testing. Are these class definitions in separate files, by chance, and is your actual test function not `main`? Global variable initialization orders could explain this, though they would all be initialized before `main` is executed.
To answer the first part, I'm using structs, not classes, so that's a flaw in the example. It does indeed compile, and in the given scenario, works as expected.
The structs Object, A, and B, are each defined in seperate files. The instances in question, gpObj, a, and b, are declared globally as extern, and then created globally in the cpp file that references them. The function that references them is not main, but as you say, they are all initialized by the time this code is executed.
And regardless to all other concerns, putting the green line in front of the red line fixes the problem, where there is positively no reference to the global pointer as a result of the call to a.init().
Thanks to all for considering this issue and for your feedback. Just to reiterate, no code will be posted. Feel free to conclude that you have insufficient information to understand the problem.
I don't think the answer is even in the code, at least not in any straightforward way. I think my problem is in my lack of understanding of how, where, and why memory is allocated to a large number of bulky, complex global variables. I think somewhere somehow something is getting created over top of something else, in a way that's beyond my ability to anticipate. But that's just my guess.
