On 2019-05-29 20:21, Vitaly Fanaskov wrote:
After all, STL updates approximately once in three years. So, we can easily follow all changes and update Qt API accordingly. It’s probably worth reusing something (e.g. time suffixes from chrono), but carefully.
Well, yes. If Qt _had_ a track-record of following up on STL API changes, fine. I'd actually welcome a QHash that had a node_handle interface I could use already without having to wait for C++17.
But as it stands, Qt has a track-record of a) _partially_ reimplementing std functionality, b) adding _one_ killer feature (QVector: realloc, QMutex: futex, ...) and then c) _not_ continue maintenance. The result just sits there, bitrots, while the std classes get more and more features. The Qt containers don't even, as of now, have all the C++98 API (range ctor, map doesn't even have range-erase(!)). And you can't hold move-only types in them. Surely, you're as addicted to unique_ptr as everyone else (if not, you haven't used it, yet). But to hold a collection of them, you must turn to the STL.
So, yes, this is borne out of frustration with the lack of maintenance of QtCore plumbing. I don't see that changing, and I acknowledge and understand that the focus of development has shifted towards QML.
And this is precisely why Qt should be rebased on later C++ standards: To increase interop with the ever-growing std library and "proper" C++ libraries using it, and to avoid having to maintain a copy of libstdc++ going forward. Because I have provided, from 2012-2017, about 1/4 of that maintenance work, and I can attest with confidence that this is a job for at least an FTE, probably more. And I don't see where this manpower should come from.
Thanks, Marc _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
