On Sat, 17 Oct 2009 09:52:32 +0200, Alan Grimes <agri...@speakeasy.net> wrote:
> When I was in my bath, I realized that Zoltan's version of > electronicConnector was the correct one even though it was segfaulting. > > Electronicconnector MUST be able to delete its wires. > > (If you knowingly induce a segfault, notify the list first and put > enough comments around it so that people don't go blaming you). (seems > you didn't, my comment was not clear in that it was bypassing a segfault > either..) > > The underlying issues are these: > > 1. We want to be able to delete a wire for several different reasons. We should define the relation between connector and wire. Can a wire exist without a connector? Or without a component? It it can, we have a problem. If it doesn't, the class that creates the wire, should be responsible for deleting it. > > 2. Many different classes keep separate, redundant, lists of wires, > (some of which out of genuine necessity.) This needs cleanup.. and documentation. > > 3. When these lists get out of sync, segfaults occour. > > If we can't fix this the normal way, we'll have to go back to using > qGuardedPointers. =(((( If it works, it'd prefer to use it. Then, in a second step, check for null and write a warning, an then the qguardedptr can be removed. Still, most of the CPU time is spent in the equation solver and querying the nonlinear component's parameters (AFAIK). So we don't have big overhead of this. > > Go ahead and revert my reversion of electronicconnector with the > appropriate comment. I haven't reverted it yet, you can do it if you want. (I'll look at it when I start coding... > > The next step on this problem is to complete the suggested refactoring > of connector.h/cpp. -- Yes, I know it will be tricky. =( At least that > will reduce the number of classes involved with this bug. > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
