| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QSharedPointer is made for passing around by value. It is unclear why
in so many repeated cases a QSharedPointer is created on the stack,
then a copy of it is new'ed up, passed into a lambda to be deleted
inside it.
First, it requires an additional heap allocation. Because it's passed
as a raw pointer to QSharedPointer, however, there's also always the
danger that it's leaked by seemingly-innocuous changes such as adding
an early return from the lambda (and some of them could really use
one, with the ifs nesting several levels deep).
All this is not needed, though. It's perfectly ok to store a copy of a
QSharedPointer, by value, in a lambda, and keep one copy outside
it. Poor man's std::future, if you will.
So, do away with all that, just pass the shared pointer by value into
the lambda, and, as a drive-by, replace some ephemeral QLists with
QVLAs. In one case, replace a QPair<int, int> with a struct to make
the code using that type more accessible ('first' and 'second' are
really, really bad variable names if they, in fact, represent
'startOffset' and 'endOffset').
Also port directly to shared_ptr / make_shared. Saves one memory
allocation each, due to the co-allocation of payload and control
block, and even though there's QSharedPointer::create, which does
this, too, std::shared_ptr is simply much lighter on the use of
atomics (copying a QSP ups two ref counts, copying a std::shared_ptr
just one). Since these variables live behind the API boundary, there's
no reason not to prefer the more efficient alternative.
Change-Id: I4b9fe30e56df5106fc2ab7a0b55b2b8316cca5fe
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
|
