diff options
author | Marc Mutz <[email protected]> | 2024-05-17 15:29:12 +0200 |
---|---|---|
committer | Marc Mutz <[email protected]> | 2024-05-29 14:24:29 +0200 |
commit | c70c81b371993ca865d523bb5f37eac4eb8a972b (patch) | |
tree | a1d1b0012a27947a0ffc7e44e7ad81344f4c5f29 /src/corelib/plugin | |
parent | 39189190fee872d2e6fcaca0f5c10d0ba6a70ea6 (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