[Ktechlab-devel] Sorry, Zoltan, u were right.

P Zoltan zoltan.padrah at gmail.com
Fri Oct 23 22:37:13 UTC 2009


On Sat, 17 Oct 2009 09:52:32 +0200, Alan Grimes <agrimes at 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.
>






More information about the Ktechlab-devel mailing list