On Tuesday 19 January 2016 11:47:29 Knoll Lars wrote: > >My answer would be to use std containers exclusively, and write a > >wagonload full of Qt-level docs about them, ie. integrate them into the > >Qt docs. > > Something I would probably support if we started a new toolkit from scratch > today (even though I still don’t like some of the API naming decisions of > the STL). But we have these classes, and there are probably hundreds of > millions of lines of code out there using them. So removing them and > breaking all that code is simply not an option.
So ... that means we're stuck with them until eternity? If so, let me suggest that you put some dev force behind the containers again. They have seriously fallen behind the std ones (I remember a time when QVector outperformed std::vector, ok on SunCC without stlport, but still). Apparently, no-one from the community bothers enough about this (me included, even though I hack them a bit here and there). Status quo in libraries equals bit-rot. The containers are _not_ "good enough". E.g. QVector seriously needs to support move-only types (like unique_ptr) in a C++11 world. Oops... it never will... it's CoWed... I have nothing against a *superior* Qt replacement for std classes, with proper interop. Like QString. I don't like *inferior* solutions that not much more than internal classes which are forced onto users because they are touted as superior in the docs and unavoidable by way of being ubiquitously used in other Qt API. For every user that uses Qt because of the containers, you will probably find ten that don't/wouldn't use it for the same reason. Thanks, Marc -- Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
