-- I broke it up though so you can read that parts that you want, or go back and finish reading the parts you may have skipped.With regards to maps as arrays:
My intent is to use maps as arrays
I do that deliberately, I kinda like having that random access. Granted yeah, no doubt, that portions of my code that don't need arrays could be written to use vectors, but then two things occur:
1) I wind up throwing another datatype into the mix (While on the surface may not be an issue, it has a widespread ripple effect on many other portions of code that may expect (And need), and use maps, or storage containers that use maps because those maps will be used in functions, so forth and so on...
2) I have this hang-up about coding myself into a corner, I guess I've been burnt too many times in past years, but I'd rather code for flexibility and power then speed and lock myself down. What I mean is, if down the line I decide to rewrite something that would benefit from the use of an array-style type, now I gotta go and rewrite it, and hope I don't have to rewrite any other rippling code. The thing about maps that I like about them being used (Asside from the previous benefits I mentioned) is essentially each element is a parameter, I can jump instantly to any parameter that is stored, I don't have to iterate through the object to get to it, so the potential
performance is greater than the current actualized performance. Though, you're probably thinking right now (As I am), why would I need to jump parameters when parsing, wouldn't the normal behavior be looked at (Once they are parsed and stored into this array) in a linear fashion? And the answer, would be, probably yes, they would be. But then I go back to my hang-up on coding myself into what see as a potential corner. My philsophy and belief is: if, as I code, any corner-painting-code potentials, I come up to, is written to be as non-corner-painting-code as possible, theoryetically I will never have a problem going back and changing something. Which is pretty wishful thinking I know. Though the out of the pan and into the fire is certainly a possibility too, but this is all philosophical
Don't get me wrong I try not to waste performance, and I will be dedicating an entire phase towards performance, but with the power and speed of modern computers, it becomes less and less of an issue (Not to diminish the importance I mean...). The speed of my current code runs -blazingly- fast considering all the stuff going on in the background that it's doing; so, so far I'm pretty happy with the performance and as such, at the moment I'm able to have my cake and eat it too, so to speak (Besides, what good is the cake if you can't eat it?
) All kidding aside, I do plan on a performance phase.A slight aside:
A few days ago I ported the code to Linux to run with Valgrind, and I have an output file, but I'm not really completely sure the problem is caused by a memory leak yet. Not to mention, some of the log entries are a little cryptic. Either way, the porting kinda made a mess out of the code since things like enums can't be qualified by gcc; which to me is crazy-silly. WTH good is throwing stuff into a named enum if you can't qualify the name of the member by specifying the name of the enum it belongs to?! Now I gotta have the name of the enum prefixed to the enum members, just to ensure the member names are unique to other member names of other enums that may need to have similiar names; since essentially by removing the qualification, all enum members are implicilty put into sort of a global scope (In a sense.). This makes the point of naming enums completely and utterally moot, why not just have anonymous enums (Is that possible? I've never actually tried that), and to me, there's something bad about having anonymous anything. So I had to rename not only all members of (almost) all enums I had to make sure each reference to them throughout the code used those new names, it took close to three hours to do it by hand! I didn't trust find and replace on something on that kinda scale. Then I had spent hours trying to create a makefile and was constantly getting "Undefined reference" errors, then I tried the auto tools (autoconf, automake, etc.. to get me a proper makefile) What a mess that was! Then I eventually found CodeBlocks would allow me to compile without a premade makefile, it must've been generating one on the fly or something (After I added all the source and header files). Unfortunately the whole effort was for the most part a waste as I said the legendary Valgrind was only marginally useful. Then there was a little disaster with svn conflicts when trying to go back. It was an absolute mess. Not in real big hurry to port to Linux again until the project is much closer to release. Fortunately, I at least know some of the things I did wrong and will be keeping that in mind as I go forward.../end_assideCurrent thoughts:
Anyhow, yeah that's the same thing I keep coming up with -- not really any obvious problem... I've spent literally days working on this stupid bug. Really wish I knew where it was coming from. I tried loading it into OllyDbg, thinking I'll get not only integration of my source (Line numbers, and direct locating via double-clicking on the asm lines), but also the ability to not deal with the gory stl code (Giving me my desired Skip-Over-System-code feature.). Unfortunately, it seems there's a jmp to an address, and when I double click that address, Olly crashes. It may be because it's the 2.0 version which is in alpha 4 status; maybe I'll give it another shot tomorrow using a lower more stable version.
Ya know, it'd be so acceptable if the object wasn't being set from the first function call, I could say, well it went out of scope and maybe there was a pointer issue, blah blah blah, but the object persists, coming out of the function and into the next, and breaks when it goes into that second function. It makes like no sense. And it's not even like half-way or 3/4 of the way into the second function (At which point I'd be thinking: Ok, well maybe I messed it up by setting it to something somewhere in "here"), it's at the begining! Which makes me think stack. But it's on the heap and the object has been demonstrated to persist as it gets set and then continue to persist going into the function. I don't get it. There's only a couple of really "out there" cases I can think of.
Case 1: An = operator is being triggered by the pointer being copied via the thunk (Proper term here?) for the function (Though I think copys of pointers only occur if they are passed in as function parameters, not sure). Not sure what happends if a method of that pointer is called and that method operates on its on members. Probably the expected result, no major problem; because it seems like such a basic question. Further more, the this keyword implies that it's expected that people will write code that will call the method of an pointer object that operates on its members.
Case 2: I've read of a case where methods can commit suicide (Usually in smart pointers that deal with reference counters and supposedly in COM interfaces), however a number of caveats exist, one of them being that if delete is used on a class member, the member is deleted as it should be (The dtor is called, then the memory is freed), and the memory is freed; if delete is used on a class and that class is declared in a function, the delete will call the class's dtors (After the member dtors, of course) and, If its dtors issue a delete this, bad things happen because the delete keyword behaves as if its operating on heap memory when it's really in stack. (It was a really weird example, I may not be remembering it quite correctly.). This is significant not in the literal sense, but in the sense to demonstrate that there can be scenerios where one believes they are working with the heap when in fact they are working with the stack. I'm wondering if I'm in a similiar situation, though I don't think I am explicitly calling the destructors in any of my classes (Or sub-classes) potentially involved; though I'll have to double check this. I know for sure that I'm not issuing any "delete this;" lines, that much is for certain.