| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
The patch adds handling for a case when a QVector is shared between two
threads. In such scenario detaching in one thread could collide with
destruction in the other one, causing a memory leak or assert in debug
mode.
Task-number: QTBUG-29134
Change-Id: Idbff250d9cfc6cf83174954ea91dbf41f8ea4aa4
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
| |
Change-Id: Ic804938fc352291d011800d21e549c10acac66fb
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
|
|
|
|
|
|
|
|
| |
Task-number: QTBUG-27391
Change-Id: I68b37ffa645be21d4d23b205bc052540b9aba7f4
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: João Abecasis <joao@abecasis.name>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
remove() can use non-detaching iterators internally before calling
erase(), which hasn't been exploited so far, so that the detach() in
erase() never actually detached. When using erase() from outside,
you can't do it legally without calling begin() or end() that detach()
before erase() is called.
Now remove() doesn't detach anymore, and detaching in erase() works.
With new tests that fail after changing only the erase() callers
and pass again after fixing erase().
Change-Id: I47c0a9e362dce8628ec566f5437d951755de96c8
Reviewed-by: Thorbjørn Lund Martsum <tmartsum@gmail.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The IA-64 C++ ABI does not encode the return type for non-template
functions (QVector is the template, not the function), which means that
these two functions have the same signature:
Node *QVector<Node>::begin()
typename class QTypedArrayData<Node>::iterator QVector<Node>::begin()
[both are _ZN7QVectorI4NodeE5beginEv]
When linking compilation units compiled with different
QT_STRICT_ITERATORS settings, only one of the two out-of-line copies
will survive. Depending on the ABI, we may have a problem: the ABI can
say that a function returning a structure takes an implicit first
parameter, which a function returning a regular pointer doesn't.
Task-number: QTBUG-27277
Change-Id: I57a59e5a7c46f55faabfe85c073dca89d2a7bbf3
Reviewed-by: Jan Kundrát <jkt@flaska.net>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
| |
Change copyrights and license headers from Nokia to Digia
Change-Id: If1cc974286d29fd01ec6c19dd4719a67f4c3f00e
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
|
|
|
|
|
|
|
|
| |
for faster bootstrapping without a full syncqt run
Change-Id: I648f0a8fb09be021590c46e8e5e15667a316c817
Reviewed-by: Qt Doc Bot <qt_docbot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
When appending a QVector to an existing vector the code would
unconditionally realloc the vector instead of first checking
whether we can do without. This gives a quadratic behaviour when
repeatedly appending a vector to another.
Change-Id: I2cd81253e6a8aec0bc4402e6fbda262435080966
Reviewed-by: Qt Doc Bot <qt_docbot@qt-project.org>
Reviewed-by: Simon Hausmann <simon.hausmann@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
qvector.h:459:30: warning: destination for this 'memcpy' call is a
pointer to dynamic class 'QImage';
vtable pointer will be overwritten [-Wdynamic-class-memaccess]
::memcpy(dst, srcBegin, (srcEnd - srcBegin) * sizeof(T));
~~~~~~~~ ^
qvector.h:459:30: note: explicitly cast the pointer to silence
this warning
::memcpy(dst, srcBegin, (srcEnd - srcBegin) * sizeof(T));
^
(void*)
QImage inherits from QPaintDevice, which has virtual functions.
qimage.h declares QImage as a movable type, so
QTypeInfo<QImage>::isStatic is false. Hence, the memcpy codepath will
be reached when the vector is not shared.
We should trust that people declaring such type traits know what
they're doing, so silence the warning.
Change-Id: If36582f57a398fc237fb4bd4f72938fb09667118
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QVector::erase shouldn't try to make sense of iterators it doesn't own,
so the validation being done here is bogus and dangerous. Instead, it's
preferrable to assert, the user needs to ensure proper ownership.
The case of erasing an empty sequence is not checked for preconditions
to allow
QVector v;
v.erase(v.begin(), v.end());
, while being stricter on other uses.
Autotests were using ill-formed calls to the single argument erase()
function on an empty vector and were fixed. This function erases exactly
one element, the one pointed to by abegin and require the element exist
and be valid.
Change-Id: I5f1a6d0d8da072eae0c73a3012620c4ce1065cf0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
| |
These names were confusing and conflicting with standard C memory
management functions.
Change-Id: I6efe20665d2ec7ad3e00f3a806cc1843a57374d4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Initialiser lists were not tested before in the QVector rewrite, so
the older malloc call was left behind.
Also, std::initializer_list has const iterators returning const data
and broke the build in a few places where const qualifiers were
missing.
Change-Id: I3c04e58361989aa7438621cda63c7df457d7dad8
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the iterator classes into QArrayTypedData and add constBegin()
and constEnd() to that class.
I also had to add an operator T*() to the strict iterators, since
there are many places that expect the iterator to behave like a
pointer (including in QVector itself).
Change-Id: Icc5ed56ad47b013664a48eef9d31b5273aecb4e3
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@nokia.com>
|
|
|
|
|
|
|
| |
Change-Id: I39b849721f3ba790c4a9197d69ac48e98cc2f5bd
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
|
|
|
|
|
|
|
| |
It was depending on internals of Q_ASSERT
Change-Id: I3dfc0ae0438135a30961f36808dbfc3e663a5538
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
| |
Change-Id: I109f46892aed2f6024459812d24922b12358814d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes all the containers that uses QtPrivate::RefCount
(QMap already had one), and QVariant
In Qt 4.8, it was pointless to have the move constructor because we did
not have quick way to re-initialize a null container. (shared_null still
needed to be refcounted)
But now that we have RefCount, and that the shared_null do not have
reference count, we can implement a fast move constructor that do not generate
code to increment the reference count.
Change-Id: I2bc3c6ae96983f08aa7b1c7cb98d44a89255160b
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just like qMalloc/qRealloc/qFree, there is absolutely no reason to wrap these
functions just to avoid an include, except to pay for it with worse runtime
performance.
On OS X, on byte sizes from 50 up to 1000, calling memset directly is 28-15%
faster(!) than adding an additional call to qMemSet. The advantage on sizes
above that is unmeasurable.
For qMemCopy, the benefits are a little more modest: 16-7%.
Change-Id: I98aa92bb765aea0448e3f20af42a039b369af0b3
Reviewed-by: Giuseppe D'Angelo <dangelog@gmail.com>
Reviewed-by: John Brooks <john.brooks@dereferenced.net>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
|
|
|
|
|
|
|
|
| |
QT_NO_STL is now no longer defined, so remove the conditionals and
select the STL side.
Change-Id: Ieedd248ae16e5a128b4ac287f850b3ebc8fb6181
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
For all practical purposes, the fallback introduced here returns the
desired value. Having a fallback enables unconditional use of Q_ALIGNOF.
For compilers that provide native support for it, Q_ALIGNOF is otherwise
#defined in qcompilerdetection.h.
Change-Id: Ie148ca8936cbbf8b80fe87771a14797c39a9d30c
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/tools/qvector.h
tests/auto/corelib/kernel/qmetatype/tst_qmetatype.cpp
Change-Id: I877256e95f3788e617437f4e9661a88047f38cd6
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
C++11 adds cbegin()/cend() functions for the same reason Qt has
constBegin()/constEnd(). This patch adds these functions to the
Qt containers with the same implementation as constBegin()/constEnd().
It also fixes the return types in the documentation of existing
constFind() functions (documentation only).
C++11 only adds cbegin()/cend() (and crbegin()/crend(), which Qt doesn't have).
In particular, it doesn't add cfind(), so I didn't supply these, even though
Qt comes with constFind().
This is a forward-port of https://qt.gitorious.org/qt/qt/merge_requests/1365.
Change-Id: Ida086b64246b24e25254eafbcb06c8e33388502b
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
The old implementation didn't compile.
Change-Id: I9892e1fff11b3a03607c468c9091eebea7e62584
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Introduced by the change of d->alloc to unsigned, in a1621d23.
Change-Id: I9e6d7fc2efbf5228c4e59c7128b8c89cf284db24
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Kent Hansen <kent.hansen@nokia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The new layout matches that of QByteArrayData and QStringData, except
for offset which is measured from the beginning of QVectorData, whereas
in those classes it (still?) references the end of the header data.
The new layout uses an extra member for storing an offset into the data,
which will allow introducing QVector::fromRawData, similar to the same
functionality already existing in QString and QByteArray.
By not using an actual array to index array members, we also steer clear
of GCC bug #43247:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43247
Change-Id: I408915aacadf616b4633bbbf5cae1fc19e415087
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/tools/qbytearray.h
Change-Id: I03b1f3e05c9b7a45130887c522fcd9b7aa387129
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The architecture is detected at compile time based on the predefined
macros from the compiler. Don't use QT_ARCH in .pro, .pri, or .prf
files. The PNG_NO_ASSEMBLER_CODE define from libpng.pri is not present
in the current copy of src/3rdparty/libpng, so no change in
functionality is expected.
The conditional for the SUPPORT_JIT define in pcre.pri is moved to
src/3rdparty/pcre/config.h, again so that we can use the compiler's
predefined macros to detect the architecture at compile time.
Replace QT_ARCH_ARM, QT_ARCH_MIPS, and QT_ARCH_SPARC with their
Q_PROCESSOR_* equivalents.
Replace QT_ARCH_INTEGRITY, QT_ARCH_VXWORKS, and QT_ARCH_WINDOWSCE with
their Q_OS_* equivalents.
Note that this commit also effectively disables the SPARC atomic
implementation. An inline implementation for SPARC needs to be added,
or we remove the current code and instead rely on the GCC intrinsic or
C++11 std::atomic support on SPARC.
Note also that this commit does not remove QT_ARCH from configure or
qconfig.h. This will continue to be set until all Qt 5 projects can be
moved away from using QT_ARCH.
Change-Id: I5de747cc4436d21941329974cff3016970f497b8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This includes padding necessary to align the data array, but excludes the first
element as was done before. Size of header is the interesting piece of
information, anyway.
This simplifies calculations in a couple of places, harmonizes code with the
QRawVector fork and paves the way for further changes in QVector, namely the
memory layout.
When Q_ALIGNOF is not available, default to pointer-size alignment. This
should be honoured by malloc and won't trigger use of more expensive
aligned allocation.
Change-Id: I504022ac7595f69089cafd96e47a91b874d5771e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For non-movable types (QTypeInfo<T>::isStatic), QVector would grow the
array linearly, and defer to qAllocMore otherwise. That property,
however, gives no indication as to how the vector will grow.
By forcing additional allocations for growing containers of such types,
this penalized exactly those objects which are more expensive to move.
We now let qAllocMore reign in growth decisions.
Change-Id: I843a89dcdc21d09868c6b62a846a7e1e4548e399
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The feature was introduced in commit 83497587b2 (2004, private history),
to allow static containers to remain uninitialized until needed.
This finishes reverting said commit. The feature had been silently
removed from QByteArray and QString in commit a5a0985476 (2004, private
history); removed from QList in aef03d80f7.
Change-Id: I9947be7758d5730d2d6e6eb2a8a308db6e9bef39
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/tools/qstring.cpp
Change-Id: I23d214bf33c2badfae1876da3cc7d6d8f6e635fb
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As in the past, to avoid rewriting various autotests that contain
line-number information, an extra blank line has been inserted at the
end of the license text to ensure that this commit does not change the
total number of lines in the license header.
Change-Id: I311e001373776812699d6efc045b5f742890c689
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These defines were there to aid in the commercial
licensing scheme we used long ago, and are no longer needed.
Keep a QT_MODULE(x) define so other modules continue compiling.
Change-Id: I8fd76cd5270df8f14aee746b6cf32ebf7c23fec7
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
|
| |
| |
| |
| |
| |
| |
| | |
Replace Nokia contact email address with Qt Project website.
Change-Id: I431bbbf76d7c27d8b502f87947675c116994c415
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QVectorData::allocate is able to handle higher alignment that
QVectorData::malloc didn't.
This was kept for BC issues in the 4.x series, we can drop it now.
Change-Id: I7782bd2910de6b9c8dee3e63e621629dc3889d33
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
|
|\|
| |
| |
| | |
Change-Id: I2d358b912f1055ee6021d13de2f66fd459aaa355
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It is mostly not used (most places in Qt use typename directly), so
is already not very useful.
For example typename is used in:
QDataStream& operator<<(QDataStream& s, const QVector<T>& v)
Change-Id: I85337ad7d8d4ebbb424bfa2ab9a356456ff3e90f
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
|
| |
| |
| |
| |
| | |
Change-Id: I02f2c620296fcd91d4967d58767ea33fc4e1e7dc
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
|
| |
| |
| |
| |
| |
| |
| | |
Note: This constitutes a break in Binary Compatibility.
Change-Id: I050587901725b701f20dd46475ae48aec28aa54d
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
|
|/
|
|
|
|
|
|
|
|
|
|
| |
, and make it strictly a POD struct.
Since this operator was only being used to set the initial (owned) value
of the reference count, the name of the function introduced here to
replace it makes that use case explicit.
Change-Id: I2feadd2ac35dcb75ca211471baf5044a5f57cd62
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Functions that modify the d-pointer must detach or otherwise take
measures to not modify the const, read-only shared_null.
The setSharable(bool) function takes care to detach when setting
sharable to false, but should avoid setting the sharable data member
unless d is not the shared null.
Similarly, QMap<Key, T>::setInsertInOrder() needs to detach if it is
shared with the shared_null (the logic has been updated to be the same
as setSharable()).
Change-Id: Ida5cb9818b86695f1b9f0264418b955c56424898
Reviewed-on: http://codereview.qt-project.org/5929
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Reviewed-by: Jan-Arve Sæther <jan-arve.saether@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Similar to QByteArray and QString, keep the shared_null in shareable
memory and never modify it.
Since QRegion uses the internals of QVector, we need to make sure that
QRegion also never modifies the shared_null.
Change-Id: I809e5873fe414138f97d501e05458b73c04b18fb
Reviewed-on: http://codereview.qt-project.org/4529
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
|
|
|
|
|
|
|
| |
Updated version of LGPL and FDL licenseheaders.
Apply release phase licenseheaders for all source files.
Reviewed-by: Trust Me
|
|
|
|
|
|
|
|
|
|
|
| |
Fix a bug in QVector::append(), it should use the capacity for new size,
when it is implicit shared and capacity is bigger than the new size.
Autotest included.
Task-number: QTBUG-11763
Reviewed-by: joao
Reviewed-by: Olivier Goffart
|
|
This is the beginning of revision history for this module. If you
want to look at revision history older than this, please refer to the
Qt Git wiki for how to use Git history grafting. At the time of
writing, this wiki is located here:
http://qt.gitorious.org/qt/pages/GitIntroductionWithQt
If you have already performed the grafting and you don't see any
history beyond this commit, try running "git log" with the "--follow"
argument.
Branched from the monolithic repo, Qt master branch, at commit
896db169ea224deb96c59ce8af800d019de63f12
|