[Qt-interest] Qt Containers (or: why I must use STL)

[Michael Bieber]

> Aside from personal preference, I would guess the two main reason Qt has 
> its own data containers are (1) for implicit data sharing, which is very 
> useful for a lot of GUI stuff, and (2) to create clean and simple 
> functions which can easily be used with signals and slots.

I agree, these are good things. As long as people use it like another 
poster suggested it - for specific Qt stuff, not intermingled with 
anything else, with discipline in general - OK. Problem is, temptation 
is out now. Being knowledgable about the C++ Standard Library gives the 
freedom to evaluate the right tool for the right task.
And here another reason for introducing the Qt containers comes back to 
my mind - to rope in Java programmers with 'comfortable' classes. I 
found these 'half-educated' people later on in projects, generously 
using the new containers out of context, because it war 'so convenient'. 
Repairing the design was a little bit work. It's not simply about 
replacing QVector by vector, it's build system, licenses (at this time), 
the wish to have software modules free from Qt for several reasons, etc..
Of course, also problems with the different interface, adaptiveness to 
standard algorithms (another abomination: QtAlgorithms) if used with the 
'Java-style' iterators (yes, the former Java programmer uses them of 
course - and C++ algorithms, who cares?).

> Although it makes the Qt API larger, I don't think it's 'fat' so much as 
> 'muscle' because it takes away from rather subtle (and dangerous) 
> responsibilities away from the user code in a safe way.

Maybe I'm too old-school, but I dislike pampering (at least beyond some 
well-defined but hard to explain point, but has very much to do with the 
completeness-minimalism trade-off). I'm one of the guys, still using raw 
pointers at times.

Micha