[Ktechlab-devel] ugh

[Alan Grimes]

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.

-- 
|/-\|/-\|