| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QDataBuffer assumes that its template argument is a POD, iow: it's ok
to not run ctors and dtors and assign a value into uninitialized
memory.
In Qt, we call that Q_PRIMITIVE_TYPE. Asserting that the QDataBuffer
value_type is not QTypeInfo::isComplex, however, has shown that a
large number of types had not been marked as such, sometimes for good
reason, e.g. because their default constructor doesn't
value-initialize all members, but sets some of them to -1.
Since QDataBuffer doesn't memset the memory to zero, it doesn't
matter, as the code obviously has to have worked before, with
uninitialized memory, and all-zeros is just a special, if common, form
of uninitialized memory.
I also tried to assert is_pod in QDataBuffer (working around the fact
that that particular trait is deprecated), but found that almost none
of the types in question were, in fact, trivial. We should fix this,
because it means the compiler is generating code that's less efficient
than it could be, but that's for another patch.
All types marked as Q_PRIMITIVE_TYPE in this patch are private API, so
this doesn't affect users.
For PathSimplifier::Event, had to shorten the unnamed namespace to not
include the member functions, because Q_DECLARE_TYPEINFO cannot appear
in a namespace other than the Qt one.
Pick-to: 6.4 6.3
Change-Id: I4431a2f269ec1ac4804a87ea71f983eaa34ef867
Reviewed-by: Tor Arne Vestbø <[email protected]>
Reviewed-by: Lars Knoll <[email protected]>
|
