Thank you very much for your detailed explanation about Qt's container design philosophy. Your insights into the historical context and technical considerations are greatly appreciated. I now better understand why Qt maintains its own implementation for QList/QVector - primarily for deep ecosystem integration, COW semantics, and enabling efficient type conversions like between QString and QByteArray. My specific interest is in implementing COW (Copy-On-Write) semantics for basic containers in my project. Given that I don't require the complex cross-type transformations or deep ecosystem integration that Qt needs, I'm considering a approach similar to how Qt wrapped std::map for QMap: creating a straightforward wrapper layer around std::vector to add COW functionality, rather than building a completely custom implementation. Do you think this would be a feasible and reasonable approach? Are there any particular challenges or considerations I should be aware of when implementing COW semantics around std::vector in this manner? Thank you again for your time and expertise. Best regards, chaoyang ---- Replied Message ---- | From | Thiago Macieira<[email protected]> | | Date | 11/11/2025 23:17 | | To | [email protected]<[email protected]> | | Cc | xiaochaoyang0214<[email protected]> | | Subject | Re: [Interest] Inquiry Regarding the Implementation Method of QT COW Containers | On Tuesday, 11 November 2025 03:54:23 Pacific Standard Time xiaochaoyang0214 wrote: Hello,
I'm sorry for the disruption, yet I've encountered a query while delving into the Qt container source code. Specifically, I'm curious as to why Qt 6 employs std::map for QMap, but opts not to use std::vector for QList and QVector. We've had our implementation of arrays since 2001, with Qt 3.0's QValueList, rewritten in Qt 4.0 as QList and QVector (still distinct types). Using our own backend allows us to implement COW more simply and also allows us to transform a QString into a QByteArray (or vice-versa, but usually memory constraints don't allow that to happen). We had our own map implementation from that time too. However, by 6.0, it was felt that our implementation was deficient. Instead of rewriting it like we did for QHash, we decided it wasn't worth our time and simply wrapped std::map. Given that the Qt team has chosen std::map as the foundational implementation for QMap, I wonder why an analogous approach wasn't taken for QList and QVector. Why not simply rework them as straightforward wrapper layers atop std::vector, in a manner similar to how std::map serves as the basis for QMap? Historical context: the question you need to ask is why we've rewritten QMap and not the other classes. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCG - Platform & Sys. Eng.
_______________________________________________ Interest mailing list [email protected] https://lists.qt-project.org/listinfo/interest
