Things To Look Out For In Reviews
Jump to navigation
Jump to search
QMap / QMultiMap
- Avoid using QMap unless you really need the implicit sharing it adds on top of std::map. You do not need implicit sharing if the map is never copied. Passing into and returning from a function, and copies that can be replaced with moves don't count. Rationale: Since Qt 6.0 QMap is merely a shared pointer around std::map. Using std::map, which gets instantiated anyway, tends to save 1.7KiB in TEXT size on optimized GCC 11 builds, sometimes much more, compared to QMap use. That's almost 2KiB of executable code size the CPU does not need to chew through at runtime to do the exact same thing. References: Commit messages in https://codereview.qt-project.org/q/topic:q-to-std-map.
QSpan
- If using QSpan as an octet buffer, always use QSpan<std::byte> (or the fixed-sized version of it), not QSpan<char> or uchar. Rationale: QSpan<std::byte> is readily created from a span of different type using as_writable_bytes(). There is no such function (neither should there be one) for QSpan<char>.
- Exception: When replacing an API that took char or uchar arrays (e.g. as QByteArray(View)), it might make sense to overload on QSpan<char> and/or QSpan<uchar>. These overload should call the std::byte one, converting their arguments using as_writable_bytes().
- Consider adding a span-of-byte-array-view or span-of-span overload to provide a scatter-gather API, like POSIX iovec / readv / writev. Example: QCryptographicHash::hashInto()