[Ktechlab-devel] Death to QT container classes!!

[Axel Jäger]

> Correct, but then whichever library we use will build upon the  
> language
> headers and the standardized libraries.
Actually, I see Qt as a replacement of the standard library.

> Therefore our first preference
> should always be to use the standardized base and then choose other
> implementations only when they offer key features not available in the
> stnadard libraries. Here we just want a bag of pins/connectors/etc,  
> and
> the perfect class for that is std::set. There is no reason to go
> shopping for a different container unless there's a compelling  
> reason to
> do so.

> The simulation engine should be isolated from the UI in any event.


If you want to keep the simulator core seperated from the GUI and use  
std::* in the simulator and Q* in the GUI, that's perfectly fine for me.

But please do not do stuff like std::list<QObject*> and friends Qt  
uses QList as native container and you can directly store them in  
QVariant, serialize them to IO-devices and stuff. So indeed there are  
some pros in using the Qt containers. Qt itself returns a lot of  
QList's (For example, QObject::children) so you cannot replace all  
QList by std::list and end up with a mix. And there is plenty of  
algorithms in QtAlgorithm.

Again, if you want to have two layers and one depends on Qt, the other  
does not, then its ok. But for the GUI part I'd prefer not to include  
a single standard header and only include every Qt-header that makes  
sense. If you go with the two layers, you would have to write wrappers  
to map std::* to Q* in order to stuff like pass a list of lines to  
QPainter to draw them (void QPainter::drawLines(QList<QLineF> lines));  
Lots of glue code and I think you lose some of the benefits in using Qt.