On 02.07.26 14:35, Bogdan Vatra via Development wrote: We do exactly this today (an in-house bimap between ids and items), and yes, it works, a lookup miss is how we detect a stale index. But look at what it costs: a parallel data structure that must be maintained in lockstep with the model, CRUD on the map for every item created or destroyed, and a lookup on every single access, on the hottest path in model/view. And every author of a dynamic model has to hand-roll this same boilerplate; it is reference counting, reimplemented badly, once per model. A shared_ptr in the payload is the same validity guarantee for an O(1) refcount and zero bookkeeping. And it doesn't help Qt's own proxies either way: QSortFilterProxyModel cannot use my application-level bimap, so its internalPointer crashes remain no matter how good my map is.
I've read the thread so far, and I'm missing concrete bugs that back up the claim that Qt itself crashes. Note that internalPointer() can already contain arbitrary data (if you new it up), but since the model isn't presented QMIs for disposal, you, indeed, need a side data structure to keep track of what was new'ed up and pushed out to users. This is not a conceptual problem, since, as Volker noted, the model knows when those entries go stale and can clean said data up. Like Volker and Peppe, I would expect this proposal to not be a slam-dunk until you can provide a bug that cannot be fixed in the current scheme, or where the side data structure doesn't work. MT is not an argument. As QObjects, Q*IMs are inherently non-re-entrant (event handling), so you cannot hope to modify the underlying storage from a secondary thread directly. Either there, or at the intersection between the storage and model implementation, you need queued updates. On cost: rather than debate this in the abstract, I went ahead and implemented it for Qt 7: https://codereview.qt-project.org/c/qt/qtbase/+/749550. QModelIndex does lose trivial copyability, but an empty payload costs next to nothing at copy time, so only models that opt in actually pay. I'll attach benchmarks for the index-heavy paths (views, QSFPM) to the review, so we can settle the cost question on numbers rather than assumptions. I note that the measurements are not up there, yet, a week after announcement. So can we assume that the costs that Volker and Peppe have feared have, indeed, materialized? Your patch shows a different problem: by adding QVariant to QMI, you make QVariant(QMI) non-noexcept. While you propose this only for Qt 7, where we can break BC and SC, I'm questioning whether users will realize they need adjust their exception specifications when they go from Qt 6 to 7. Thanks, Marc -- Marc Mutz <[email protected]><mailto:[email protected]> (he/his) Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io<http://www.qt.io> Geschäftsführer: Mika Pälsi, Juha Varelius, Juha Puputti Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B Public
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
