[Ktechlab-devel] code cleanup and connector lists

[P Zoltan]

On Thu, 04 Dec 2008 12:23:24 +0100, Julian Bäume <julian at svg4all.de> wrote:

>
>>    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.

   This is a minor problem for porting to qt4; can be fixed in
search-replace style.

>> 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.
>>

This would look like:

class FlowConnectorList : ConnectorList {
  private:
   QValueList<QGuardedPtr<FlowConnector> > list;
  public:

   typedef QValueList<QGuardedPtr<FlowConnector> >::const_iterator  
const_iterator;
  // ...
const_iterator begin() const { list.begin() }
  // so on for all members...
// see members here: http://doc.trolltech.com/3.3/qvaluelist.html

};

  I'm curious if this compiles...

>> 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?).

  C-style and java-style iterators? How are those?

   I haven't thought much about the details, I sketched only principles. For
c) the idea would be to change the interface -- somehow. A rudimentary  
solution could be

int getConnectorCount();
Connector * getConnector(int number);

  :))

  I have to read some more on the topic, to see what to do...

   After searching through the source. I've found that connectorList() is
used in ~10 places, so it's not a big deal to change the interface.

>
>>   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,....)

   With *ConnectorList I've referred to ElectronicConnectorList,
FlowConnectorList and ConnectorList, not a pointer to some list :)


>
>>   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.

   So this remains for the qt4 port. But one thing that we could do is to
document use cases, which could be used to write the actual tests. See
here:
http://ktechlab.org/wiki/index.php?title=Devel:Existing_architecture#Features_.E2.80.93_detailed

>
> 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.
  I'm very busy with university stuff too. And it will get only worse until  
february.

   Zoltan