> On 10 Jul 2015, at 14:24, Marc Mutz <[email protected]> wrote: > That just goes to show how bad of an influence QList has. But it never hid > its > design, and, indeed, the "default container" in Qt 3 was QValueList, which > actually *was* a doubly-linked list. Why Qt always nominates a list as the > default container while the STL recommends std::vector is one of the > mysteries > to which only Trolls know the answer :)
QList is the perfect default container for applications that value convenience and intuitiveness over best performance (a typical feature for most APIs in Qt), but it still outperforms arrays and linked lists for the most common operations for complex types, such as insertion and removal. The two most useful examples of QList usage in Qt applications are QList<QWidget *>, and QList<QImage>. To cater for the problem of custom complex types, all types in Qt were made shallow (the shallowness of containers and smartness of QList when used with shallow types go hand in hand, which is another typical feature for APIs in Qt). It should be no surprise to users that creating a QList of 100 QImages does *not* lead to 100 news or mallocs. Qt APIs also help programmers avoid making mistakes. QList has the undisputable advantage of allowing lists of dynamic sized elements. It’s a common programmer’s mistake to run into trouble with lists of dynamic elements when those elements are stored in arrays. Trouble leads to hacks leads to bugs. It doesn’t take too much imagination to understand how much of a pain you can run into, and what horrors could be applied to work around, creating a QVector of QVectors. The problem is a bit hard to grasp for some developers, and using QList you just don’t run into those problems. So, I dispute the general -1 of any use of QList. Use yours brains, and -1 where brain has not been applied. ;-) Andreas _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
