Every bit combination is a valid object, so the
correct type classification is primitive, not
just movable.
This is BC, because it just changes whether
the default ctor and dtor are run or not,
and these types don't care.
Change-Id: Ifbfa83128778744f15a086a65c8be1ce01a58820
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
The compiler-generated move operations are ok.
Change-Id: Ida994b52e3ee6ce75afd50133e61488b94464eee
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
These types are larger than a void*, so holding them in QLists
is needlessly inefficient. Worse, the code could come to depend
on the fragile property of (inefficient) QLists that references
to elements therein never are invalidated.
Fix by marking them movable, and holding in a QVector instead.
Change-Id: I74b2ce327d6aee60e2cc3463ce09453a4305bba7
Reviewed-by: Dmitry Shachnev <mitya57@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is low-hanging fruit, for two reasons:
1. The implementation is dead-simple (unlike, say, in QList).
2. It's completely transparent to the QVector user (unlike,
say, emplace_back, which can only be used inside an ifdef).
Change-Id: Iaf750100cf61ced77aa452f0e4e3c4ec36b29639
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
It doesn't save any space, is not required for ABI compat
(because it's private API), generates more code to extract
the field, and triggers a bug in older GCCs when synthesizing
a move constructor for this type:
src/gui/image/qiconloader_p.h:64:8: error: invalid conversion from 'unsigned char:4' to 'QIconDirInfo::Type' [-fpermissive]
src/corelib/tools/qvector.h:641:13: note: synthesized method 'QIconDirInfo& QIconDirInfo::operator=(QIconDirInfo&&)' first required here
Change-Id: I61e886566b67c7a18a318a3d026dc762600f8ab4
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
... except if the function is a ctor, callers pass rvalues,
and the type has a fast move ctor. In that case, keep passing
by-value and qMove() into place.
Change-Id: I2c0be7d4436327834ddee0531c51c5af352ac74c
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Makes for much more readable callers, and, d/t NRVO, isn't less efficient
than the old code, either. Transparently enables moves when QVector should
get them, at some point, too.
Change-Id: I77327cf665272b80277deaaa6dd2ee9c00806464
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
FileInfo is larger than a void*, so holding them in a QList is needlessly
inefficient. Worse, the code could come to depend on the fragile property
of (inefficient) QLists that references to elements therein never are
invalidated.
Change-Id: I772177c5ac544a5fecce2368f628148308ef260f
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
- don't define special member functions if the compiler-generated
ones are just fine (inhibits move semantics)
- implement all remaining methods inline
- unexport
- remove unused (and, to add insult to injury, never init'ed)
d-pointer. This is private API. No need for a d-pointer,
much less an unused one.
Change-Id: I6979cb5103a361c0313c252d3bf7073a3c47addd
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
They do the right thing (except move special member functions
on MSVC, but that's MSVC's problem).
Change-Id: I699e1be83c0568821f8c6b84394a2713bb22e8e7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
[ChangeLog][QtCore] All generic containers (with the exception of
QVarLengthArray, but including QSharedPointer) destroy the
previous state as part of a move-assignment now. Previously, they
would dump it into the right-hand-side object. Note that this is
only true for the generic containers. Other implicitly-shared
types, as well as the non-generic containers QString, QByteArray,
etc. still just swap the contents with the right-hand-side object
when move-assigned into, and, for performance reasons, this will
not change in the forseeable future.
Change-Id: I1f1c684e85400b77bd2e7fba65bde2dce6c1bdde
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Requires adding member-swap and (at least in my copy) move operations.
Change-Id: I1b638a81e4a41f467e69e352806524039e7b9f27
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
These all invoke the QFlags<>(Zero *) ctor, which is designed to
accept a 0, but no other int. But in doing so, it requires passing
a nullptr literal, and 0 is not a nullptr literal accepted under
-Wzero-as-null-pointer-constant or similar warnings.
Fix by using the QFlags::QFlags() ctor instead.
Task-number: QTBUG-45291
Change-Id: I73f9c9f4de11eeb1ba04ace6c7121d17510ea29f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is in preparation of adding -Wzero-as-null-pointer-constant (or similar)
to the headers check.
Task-number: QTBUG-45291
Change-Id: I6f591a42a8e8ea471d27666eb1cbc77b572b3e0d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is in preparation of adding -Wzero-as-null-pointer-constant (or similar)
to the headers check.
Task-number: QTBUG-45291
Change-Id: I72ab40b21a9499b53a639564fa45884de17b6c98
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is in preparation of adding -Wzero-as-null-pointer-constant (or similar)
to the headers check.
Task-number: QTBUG-45291
Change-Id: I9a05d375d2d9d3ed56079ad024c89a08a290619b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It was added for NokiaX86 / RVCT compilers and may
produce unexpected results with g++, where it matches
for qCompare(int, enum).
Task-number: QTBUG-47260
Change-Id: Ia29b9ae289c6df579a923aef6eb67e46db0b1120
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
Reviewed-by: Jason McDonald <macadder1@gmail.com>
Requires adding member-swap and (at least in my copy) move assignment.
Since the type does not contain a d == nullptr state,
a move constructor isn't yet possible.
Change-Id: Iad6939fa30f214591eab1fdf30a2cf1423ffb32a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Requires adding member-swap and (at least in my copy) move operations.
Change-Id: I4284484b1f520eb2d9036b993a5b5b70aaea0af9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Requires adding member-swap and (at least in my copy) move operations.
Change-Id: I0b32c387809c972203c94677616fe0a52143ec3b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
...by allowing to pass the column to the Private::index() overloads.
Because Private::index() always returns an index in column 0,
callers that needed a different column used QModelIndex::sibling()
to adjust the column of the returned index. But that calls
QAIM::sibling(), which calls both QFSM::index() and ::parent().
Simply allowing to pass the column number instead of hard-coding
0 avoids that heavy detour.
Change-Id: I8895b3d102d576ba291333cf61075b7263f96b9d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
Reviewed-by: David Faure <david.faure@kdab.com>
The overload was added for NokiaX86 and RVCT and is bound for
removal.
Task-number: QTBUG-47260
Change-Id: Ic67cee8769847956e16cd0470ebcd663a9e98a40
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In current implementation, d->firstRead doesn't provide any
performance improvement.
Change-Id: I5d6e765a7d49cb546998b2c3e908e3c5600e70b1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... with classical semantics, meaning movable-come-Qt6,
and complex-until-then.
Whether or not we want a new flag for movable-except-
in-QList is an orthogonal question, and should not hold
back the slew of commits that introduce use of this
macro.
Change-Id: I3a6be08c314fcd7f3315af138625c38196debda5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is in preparation of adding -Wzero-as-null-pointer-constant (or similar)
to the headers check.
Not caught by the headersclean check, because they are in template code.
Task-number: QTBUG-45291
Change-Id: I7294404225a19a1c58f91e6e47a9d650179ea83c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The reverse_ ones were missing, and the non-reverse ones
were marked \internal. But why should they not be documented?
Change-Id: I5ffbfc1def8dcac3f4a771883152ffbcca3d745d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The new constructor cannot be marked nothrow, because it calls
non-nothrow doCheck();
Change-Id: I4e5b33c58125091644573ed84e715c7fa946ae09
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The new constructor cannot be marked nothrow, because it calls
non-nothrow doCheck();
Change-Id: I732fac7a07d46a3ff3be0e4e56de72dd19090737
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
They are held in QVariants. No need to allocate
them on the heap.
Change-Id: I7829acbed94fd5b37079df670b0aa2d09613c73c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The compiler-generated move operations are ok.
Change-Id: Iec0fed49d52ace5ca7dae2c7ee53d717a283f15a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Because the MS standard library headers won't have the necessary
constexpr markings, some types that should be literal (like std::atomic)
aren't and some functions that should be constexpr (like
std::numeric_limits:max()) aren't.
Change-Id: Ib306f8f647014b399b87ffff13f1c74093b11af1
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
If you're running Qt under valgrind, it stands to reason that you know
what you're doing.
In particular, Valgrind does support AVX and AVX2 instructions, but some
versions seem to be missing the necessary CPUID bits.
Change-Id: I9a75ad8521ae4e5cbbe5ffff13d1940f6fa5c4f4
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: David Faure <david.faure@kdab.com>
wait4 gives us the struct rusage contents for us, which may contain
interesting data for other users of forkfd (not Qt, though).
Change-Id: Iee8cbc07c4434ce9b560ffff13cb4aa28e18e790
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
Long-lived threads started by Qt itself can now receive events even if
QCoreApplication hasn't been created. This is required in all threads we
start that will handle events, unless we're sure that the thread will
exit before the global application object begins destruction.
Otherwise, those threads will have race conditions dealing with the
event delivery system trying to call the QCoreApplication::notify()
virtual while the object is being destroyed.
Change-Id: I27eaacb532114dd188c4ffff13d4ad2a4bb443e6
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
This commit makes QCoreApplicationPrivate::checkReceiverThread,
notify_helper, and sendThroughObjectEventFilters be static functions,
since they only deal with global data or the parameters only.
Making notifyInternal would have been binary incompatible (it's called
from inline functions QCoreApplication::sendSpontaneousEvent and
QCoreApplication::sendEvent), so instead add a new static
notifyInternal2 and mark the older function deprecated and to be removed
in Qt 6.
Change-Id: I27eaacb532114dd188c4ffff13d59fe3b0661489
Reviewed-by: Albert Astals Cid <albert.astals@canonical.com>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Otherwise, if I open tests/auto/dbus/dbus.pro in Qt Creator, it shows me
"test", "test2", "test3", "test4" and it's very hard to know which test
is which.
Change-Id: Iee8cbc07c4434ce9b560ffff13d0654696c025b7
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>
