On Tuesday, 11 November 2025 17:44:39 Pacific Standard Time xiaochaoyang0214 wrote: > 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?
QMap in Qt 6 is proof that is feasible and reasonable for some use-cases. The challenge of wrapping a type instead of building it in from the scratch is that you need to add an extra layer of indirection. So your MyVector class, like QMap, doesn't access the data directly, but instead holds a pointer to the underlying structure, then dereferences it. Take for example this very simple function: https://qt.godbolt.org/z/bP5Es945G (at the time of writing this email, Godbolt's Qt support was broken) Please ignore the fact that they return slightly different things coming from the same source. std::map generates two loads from memory: movq 24(%rdi), %rax movq 32(%rax), %rax retq Whereas QMap inserts a third: movq (%rdi), %rax movq 32(%rax), %rax movl 36(%rax), %eax retq We figured this trade-off was acceptable, given how QMap isn't as often used as QVector and QHash, and usually isn't very performance sensitive anyway. It was offset with the decrease in our cost of maintenance. Besides, the old Qt 5 implementation may have had worse performance than this extra indirection. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCG - Platform & Sys. Eng.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Interest mailing list [email protected] https://lists.qt-project.org/listinfo/interest
