summaryrefslogtreecommitdiffstats
path: root/src/corelib/plugin
diff options
context:
space:
mode:
authorMarc Mutz <[email protected]>2024-05-17 15:29:12 +0200
committerMarc Mutz <[email protected]>2024-05-29 14:24:29 +0200
commitc70c81b371993ca865d523bb5f37eac4eb8a972b (patch)
treea1d1b0012a27947a0ffc7e44e7ad81344f4c5f29 /src/corelib/plugin
parent39189190fee872d2e6fcaca0f5c10d0ba6a70ea6 (diff)
Long live QCryptographicHash::hashInto()!
Until now, QCryptographicHash had a big drawback over the underlying C APIs: at least one extra memory allocation: Either you created a QCryptographicHash object (allocates a Private), and enjoy noexcept addData() and resultView(), or you used the static hash() function (which creates a Private on the stack, so doesn't need to allocate one), but then we needed to return in an owning container. Enter QSpan and hashInto(), which allow the user to provide a buffer into which to write, and therefore can be completely noexcept and (apart from a missing optimization which, however, doesn't affect the API) deliver near C-API efficiency. We don't have QMutableByteArrayView, which would deal with the different types of equivalent char types for us, so we overload for QSpan<std::bytes>, QSpan<char> and QSpan<uchar>, which makes the overload set accept roughly what QByteArrayView would accept, too. Return by QByteArrayView because that has a richer API than QSpan, which lacks (on purpose) string-ish API. [ChangeLog][QtCore][QCryptographicHash] Added hashInto(). Task-number: QTBUG-125431 Change-Id: I80ecc7151d3418a36c4d5db6d22d0b82c869b19f Reviewed-by: Mårten Nordheim <[email protected]>
Diffstat (limited to 'src/corelib/plugin')
0 files changed, 0 insertions, 0 deletions