Memory allocation errors when declaring variables in header files

[ohartenstein23]

This is a question to the coders out there: I've been trying to add new ruleset options for improving the interception window/minigame for OXCE+, and have run into a number of different memory allocation errors, most of which I narrowed down to how class variables are declared in the header files.  Is there a proper method for adding new variables to the header?

For example, in RuleUfo.cpp, I wanted to implement a method for getting an integer from the ufos: ruleset to point to a resource for the UFO's firing sound, copied somewhat from the methods in RuleCraftWeapon.cpp and .h.  I declared int fireSound in RuleUfo.h, and had it initialize to fireSound(-1) in the class constructor.  Compiled smoothly, but CTD at runtime.  I eventually got it to work by moving the declaration of fireSound a few lines down in RuleUfo.h, but still with all the other variable declarations.  I've done some similar additions (I can provide more specific examples when I'm not on my phone), and it has been the same story of re-ordering the declarations in the header.  It seems like black magic to me, so can anyone provide an explanation why a certain order works, and how to properly code that order without guess and check?

Edit: Thinking about it, could the memory allocation errors come from not recompiling the other .cpp files that include the header before repackaging the executable? I typically only replace the object file for the .cpp file whose header I'm editing, so in the RuleUfo example, only RuleUfo.cpp recompiles into RuleUfo.o when I edit RuleUfo.h.  Should I have found all .cpp files that include RuleUfo.h, removed their associated .o files, and then recompiled?

[yrizoud]

Whenever you modify the "prototype" of a class, every file which uses this class should be recompiled.
The fact that re-ordering methods causes a different behavior is a big hint.
There is no requirement of a specific order in a class. There is only the general principle that the C compiler works from top to bottom, so if A calls B, B must be known by the time it is used (forward declared, if necessary). When it's not, you get a compilation error, not a run-time weird behavior or crash.

Do a clean rebuild, and you're very likely to see these problems disappear.

In my own C projects, I use the system of maintaining a sub-makefile of dependencies (generated using "make depend", which calls gcc -M on all source files). I have to remember to call it from times to times, but then the makefile has enough information to automatically rebuild what's needed.

[ohartenstein23]

Thanks for the reply!  Editing OXC is my first real experience with C++, so I hadn't really thought through things like this before.  My first idea for checking dependencies was to grep for the includes of the specific header I was editing to make a script to delete and recompile all the affected classes, but if "make depend" takes care of that for me, that'd be much easier.