From: Alan G. <ag...@sp...> - 2006-12-31 00:38:35
|
Drew Noakes wrote: > hey alan, > > i don't even use ktechlab but one day i'd like to (when i can devote the > time to it). in the meantime, i'm enjoying following your work through > the code, as i'm sure others are too despite the list being fairly > quiet. keep up the good work. > all the best for 2007. Here's the situation now... I asked std::vector to manage all of the CBranches in ElementSet. ### typedef vector<CBranch> CBranchList_T; ### Okay, my CBranches are now maintained from cradle to grave by std::vector and all I have to do is tell std::vector how many CBranhces I need. I then modified Element so that it now only records the CBranch's *index* instead of it's pointer. This actually simplifies the code in a number of places and, in the others, it simply retrieves the pointer from elementset and then discards it immediately after it is done. This means that between method invocations, exactly one pointer to each cbranch exists and it is hidden inside the STD::vector container. This method might be a bit slow in certain cases, but it is virtually phuleproof. I now have my moddedkenwood.circuit, the modified version of my kenwood Receiver's phonostage and equilizer sections. I was flying by the seat of my pants when I actually performed these modifications... They actually look pretty good in the simulation so I think I did the right thing. =P The circuit has two signal generators, two op-amps, three pots, a dozen resistors, a dozen caps, five voltage probes, etc etc... and it's all working! =P Those five voltage probes burn osilliscope data memory like crazy so I have to press reset every few minutes but that's no problem. I have several switches scattered around the circuit which I was using earlier to explore how the previous simulation engine was glitching out. I pressed one. -- UH OH!! My new simulation engine bitches about being given a bad problem. -- It was given a completely blank matrix. I trace through a bunch of stuff, cured a few bugs here and there, and now I think I've isolated the problem. -- sorta. I'm in Element::updateStatus(). type() returns that I'm a resistor. Resistors have their protected m_numCNodes variable set to 2. This is done by the constructor and it cannot be changed for the life of the object. -- in theory. Yet, when I'm presented with an object which has Resistance's virtual method table yet cbranches is = 0. Somehow, this object's memory has been trashed! =( OK, I need to clean up the pointers to class Element. Oh god. What a catastrophy! Virtually every class in the entire application contains some kind of pointer to one or more Elements of one ore more types... I would presume that the master pointer to each element is in its associated EComponent. This is actually false, it merely has a convenience pointer, the primary pointer seems to be in the ElementMapList of the base class Component. However, the elements are created by class Component. I was previously wrong when I thought Component was misdesigned by having knowledge of specific subclasses. Instead it contains utility functions for instantiating common Element types. The pointers to these new elements are both returned to the subclass and stored in the element map set... You can glance at the class list (using kdevelop) and see how many times ElementList and ElementMapList are declared. sheesh! That's going to take a long time to de-tangle. With my code only half-functional right now I'm going to be hacking blind until things start working again. =\ time for lunch. -- |/-\|/-\| |