diff options
author | Marc Mutz <marc.mutz@qt.io> | 2022-02-25 08:47:48 +0100 |
---|---|---|
committer | Marc Mutz <marc.mutz@qt.io> | 2022-03-03 00:25:14 +0100 |
commit | 6f5c78fe3d445f1c6c8738f9cedb9dbd847645fa (patch) | |
tree | bdc3d95dee98a54ab84dc30b3f5bd469f06af150 /src/plugins/platforms/wasm/qwasmintegration.cpp | |
parent | b2c7f17b940fb7735ff88d9af6e03729a2fdcdd0 (diff) |
QFlatMap: add remove_if
The existing API of QFlatMap did not allow efficient removal of
elements:
- std::remove_if does not apply, because it works by moving elements
back in the range onto those that need to be removed, which doesn't
work in flat_map's case, because, like for all associative
containers, the key in value_type is const.
- The node-based erase-loop (over it = cond ? c.erase(it) :
std::next(it)) works, but, unlike in traditional associative
containers, is quadratic, because flat_map::erase is a linear
operation.
According to Stepanov's principle of Efficient Computational Basis
(Elements of Programming, Section 1.4), we're therefore missing API.
Add it.
I couldn't make up my mind about the calling convention for the
predicate and, despite having authored a merged paper about erase_if,
can never remember what the predicate is supposed to take, so be fancy
and accept all: (*it), (it.key(), it.value()), (it.key()). This means
that unary predicates can either not be generic or must be properly
constrained to distinguish between pair<const K, V> and K, but that's
not necessarily a bad thing.
There's no reason to supply a Qt-ified removeIf on top of the standard
name, because this is private API and doubling the names would do
nothing except double the testing overhead.
Fixes: QTBUG-100983
Change-Id: I12545058958fc5d620baa770f92193c8de8b2d26
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Diffstat (limited to 'src/plugins/platforms/wasm/qwasmintegration.cpp')
0 files changed, 0 insertions, 0 deletions