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

[Julian Bäume]

Hi,

first of all, I'm against killing the Qt container classes. Let me explain, 
why this is bad:

I agree with the fact, that in Qt3 classes like QValueList somewhat forced the 
developer to misuse it to create some kind of set. The trolls might have had 
something similar in mind, when designing the Qt4 API. Just have a look at the 
new API for container classes: 
http://doc.trolltech.com/4.5/containers.html#container-classes and you will 
mention the direction. There now is QSet, which is a QHash based 
implementation to provide a container to store sets with fast look-ups. 
Sometimes order is important, so there is QMap (that has been there already in 
Qt3 with slightly different API). So again: nowadays Qt provides a nice set of 
container classes, very easy to use. Another thing the Qt classes guarantee is 
thread-safety. I'm not sure about the implementation of the STL container 
classes, the methods might be reentrant as well, also I have in mind, that 
definitions about reentrance and thread-safety sometimes differ in some subtle 
way.
There are 2 ways of using the Qt container classes in Qt4. "The Qt way" and 
"STL way". The difference is in speed (Java-Style Iterators are slightly more 
inefficient) and readability (STL Iterators are sometimes hard to read, 
especially for newbies and there are more possibilities of "doing it wrong" 
[see trolltech documentation page i mentioned earlier]).

Another thing to mention is that you can use Qt container classes together 
with STL's generic algorithms. Also Qt provides own implementations (which 
should probably be preferred, to reduce number of libraries) there might be 
some rare cases, where you need STL algorithms. When using STL containers, you 
are stuck to their algorithms lib.
So as you might see, the situation will change, when switching to Qt4 
container classes. For the simulator I'd also suggest to use the Qt classes 
and may be do critical implementations using STL Iterators. I for my self 
prefer readability over speed, especially if the differences are small. I 
guess the difference isn't noticeable in most of the cases and well, if so, 
there is the possibility to make it slightly more efficient.

well,
just my 2ct
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/20090505/a1ae5741/attachment.sig>