[Ktechlab-devel] code cleanup and connector lists

Julian Bäume julian at svg4all.de
Thu Dec 4 11:23:24 UTC 2008


Hey,

On Wednesday 03 December 2008 22:38:36 P Zoltan wrote:
>    As a code cleanup I'm plannig to separate electronics and flowparts,
> such that electornic nodes to be connected with electronic connectors,
> while flownodes to be connected with flowconnectors. Obviously buth
> connector types and node types will inherit from Connector respectively
> Node. I want to sketch here an implementation problem, to ask your advice.
I looked into that code some time ago, but haven't done deep thoughts about 
that. I guess now is the time to do so ;)

>    A FPNode has some methods which return a ConnectorList; however a
> flowconnector should keep a list of FPNodes, an electronic connector a
> list of ECNodes, so they should return something like FlowConnectorList or
> ElectroincConnectorList. The problem is that is we define
> FlowConnectorList as:
>
>    typedef QValueList< QGuaredPtr< FlowConnector > > FlowConnectorList;
> and
>    typedef QValueList< QGuardedPtr< Connector> > ConnectorList;
I stumbled about that, too. QGuardedPtr doesn't exist any longer in Qt4. 
Neither does QPointerList (as used somewhere in the code, too. IIRC). The way 
to go in such situations would be:

	QList< QPointer< Type> >

of course it's possible to use any collection type instead of QList here, but 
in most cases QList will fit best. What the QGardedPtr did was just making 
sure that there can't be a NULL-Pointer to make your program seg-fault... This 
is now handled by QPointer.

> then we can't upcast a FlowConnectorList to ConnectorList (They are not
> compatible), but Node::connectorList method is used in many places in the
> program. Here are few solutions to this problem:
>
> a.) implement all methods related to ConnectorLists using
> {Flow|Electornic}ConnectorList. This is quite inefficient because in this
> way every time such method is called, a new ConnectorList should be
> created and filled with elements from the specialized ConnectorList.
That's a no-go ;)

> b.) create the FlowConnectorList as a subclass of ConnectorList and
> override most methods. I consider this a hack.
>
> c.) redesign the interface of Node and all subclasses, such that the class
> itself won't provide a list, only an interator and associated functions --
> this way all the mess with *ConnectorList will disappear. This is more
> efficient as a), and it should be be enough for the majority of occurences
> of connectorList method.
IMHO these are both possible ways to go. So it's a design decision here, we 
should document it afterwards (so tell other devs how to use it) just to make 
things clear. Than everything should be fine. I still have some questions for 
c.).

The problem I see for c.) is what kind of iterator do you want to provide? Qt 
has both, C-style and Java-style iterators and there is the "foreach"-macro. 
You are going to limit that freedom to one possibility here (or did I get 
something wrong?).

>   My question is how should be this problem threated?
I didn't fully understand the problem, I guess. I don't see any *ConnectorList 
mess for variant b.). All collection-classes in Qt are implemented to use 
implicit memory-sharing (did I use the right term here?). What I mean is: 
There is no need for keeping pointers to these collection classes. There is 
nearly no overhead when using these classes to provide interfaces for all kind 
collections. This counts for QList, as well as for all the other types (QSet, 
QHash, QMap,....)

>   After fixing this and removing many unneded casts, I'd like to start
> fixing the bugs related to the open-save of the files. I have a feeling
> that the autorouter messes up the circuit, because sometimes dragging a
> component on the circuit has "side" effets.
>
>   Have I seen right that unit testing framework integrated in qt exists
> only from version >= 4 ? Some unit tests in the program would be really
> useful -- at least we will know if we break something.
You are right here. QTest exists only in Qt4. There is a "cppunittest"-
framework, but I'm not sure if this will be worth the effort to implement 
tests.
IMO we sould start using tests with Qt4.


Anyway. It's great to have heard something from you. I've been quite busy 
finishing another task for university and will start working on KTechLab again 
these days.

bye then
julian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 489 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/ktechlab-devel/attachments/20081204/ef28fb00/attachment.sig>


More information about the Ktechlab-devel mailing list