Various cleanups. Add copyAppend overload for forward iterators and a
insert overload for inserting n elements.
Change-Id: Ic41cd20818b8307e957948d04ef6379368defa55
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This requires that the allocation functions return two pointers: the d
pointer and the pointer to the actual data.
Ported QArrayDataPointer & SimpleVector to the inlined size & data.
For now, the size and offset members are not yet removed from
QArrayData, to let QVector, QByteArray and QString compile unmodified.
Change-Id: I8489300976723d75b8fd5831427b1e2bba486196
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The next change will stop using some values in the reference counter as
settings from the data.
Change-Id: I94df1fe643896373fac2f000fff55bc7708fc807
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The Mutable flag now contains the information on whether the data this
QArrayData points to is mutable. This decouples the mutability /
immutability setting from the allocation and from the type of data,
opening the way for mutable raw or foreign data.
There are still plenty of places in the source code that check the
size of the allocation when it actually wants d->isMutable(). Fixing
this will require reviewing all the code, so is left for later.
The needsDetach() function is moved to QArrayData and
de-constified. It returns true when a reallocation is necessary if the
data is to be modified.
Change-Id: I17e2bc5a3f6ef1f3eba8a205acd9852b95524f57
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Rename to QArrayData::ArrayOptions in preparation for these flags
being in the array itself, instead of used just for allocating new
ones.
For that reason, rename QArrayData::Default to
DefaultAllocationFlags. And introduce QArray::DefaultRawFlags to mean
the flags needed for creating a raw (static) QArrayData.
Also rename QArrayData::Grow to GrowsForward, so we may add
GrowsBackward in the future.
Change-Id: I536d9b34124f775d53cf810f62d6b0eaada8daef
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The support for unsharable containers has been deprecated
since Qt 5.3.0, so let's finally remove support for them.
Change-Id: I9be31f55208ae4750e8020b10b6e4ad7e8fb3e0e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
(or forward-declare std types)
(with apologies to Mr Walter Brown)
This applies the changes to our other smart pointers that
a0c4b6f345 applied to QSharedPointer,
with the same rationale: wg21.link/p0551.
It also fixes a fwd declaration of std::function, including
<functional> instead. Rationale: wg21.link/p684r0.
Change-Id: If275af91f6eac15eb418b200ac7d08ba084a6130
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
In preparation of Qt6 move away from pre-C++11 macros.
Change-Id: I44126693c20c18eca5620caab4f7e746218e0ce3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
That's before the return type or static, inline, constexpr or such
keywords (if any).
Perl Script:
s/^(\s+)(.*) Q_REQUIRED_RESULT(;)?(\s*\/\/.*)?$/\1Q_REQUIRED_RESULT \2\3\4/
Change-Id: I7814054a102a407d876ffffd14b6a16182f159e2
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
The C and C++ standards say it's undefined whether the preprocessor
supports macros that expand to defined() will operate as an ifdef.
Clang 3.9 started complaining about that fact.
One solution was to change QT_SUPPORTS to check for zero or one, which
means we need to change the #defines QT_NO_xxx to #define QT_NO_xxx 1.
The C standard says we don't need to #define to 0, as an unknown token
is interpreted as zero. However, that might produce a warning (GCC with
-Wundef), so changing the macro this way is not recommended.
Instead, we deprecate the macro and replace the uses with #ifdef/ndef.
Change-Id: Id75834dab9ed466e94c7ffff1444874d5680b96a
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new LGPL header instead of LGPL21 one
(in those files which will be under LGPL v3)
Change-Id: I046ec3e47b1876cd7b4b0353a576b352e3a946d9
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
QArrayData::allocate() uses malloc() which can return 0. We need to
check for that when using it inside other containers. The containers
might otherwise return a seemingly valid result from some allocating
operation which is actually corrupt.
Task-number: QTBUG-41231
Change-Id: I16cc6035e4f495f519bd38bf29cee080ee0637f6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
The ability to set a container to be unsharable has very little use and
it costs us an extra conditional for every refcount up and possibly
down.
This change is a no-op for current Qt 5. It shuffles a few things around
just so Qt can compile if you define QT_NO_UNSHARABLE_CONTAINERS. That
is done to ease the fixing of the code in Qt 6 and to make my life
easier: I'll keep that defined in my local Qt build so I can catch any
misuses of this deprecated API.
The newly deprecated methods are not marked QT_DEPRECATED because the
bootstrapped tools wouldn't build -- they're built with QT_NO_DEPRECATED
defined, which causes build errors.
[ChangeLog][QtCore] The setSharable() and isSharable() functions in Qt
containers has been deprecated and will be removed in Qt 6. New
applications should not use this feature, while old applications that
may be using this (undocumented) feature should port away from it.
Discussed-on: http://lists.qt-project.org/pipermail/development/2014-February/015724.html
Change-Id: I789771743dcaed6a43eccd99382f8b3ffa61e479
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
The macro was made empty in ba3dc5f3b5
and is no longer necessary or used.
Discussed-on: http://lists.qt-project.org/pipermail/development/2013-January/009284.html
Change-Id: Id2bb2e2cabde059305d4af5f12593344ba30f001
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Reviewed-by: hjk <hjk121@nokiamail.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>
QArrayData can point to data it does not own (cf. fromRawData()), which
shouldn't be modified. Not even upon destruction, as this data can live
in Read-Only memory or be otherwise shared outside the QArrayData realm.
Change-Id: I8bdf3050a17802fb003b77d5f543fe31769a7710
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Andreas Hartmetz <ahartmetz@gmail.com>
While QArrayDataPointer offers generic detach() functionality, this is
only useful for operations that may modify data, but don't otherwise
affect the container itself, such as non-const iteration, front() and
back().
For other modifying operations, users of the API typically need to
decide whether a detach is needed based on QArrayData's requirements
(is data mutable? is it currently shared?) and its own (do we have
spare capacity for growth?).
Now that data may be shared, static or otherwise immutable (e.g.,
fromRawData) it no longer suffices to check the ref-count for
isShared().
This commit adds needsDetach() which, from the point-of-view of
QArrayData(Pointer), answers the question: 'Can contained data and
associated metadata be changed?'.
This fixes QArrayDataPointer::setSharable for static data (e.g.,
Q_ARRAY_LITERAL), previously it only catered to shared_null.
SimpleVector is also fixed since it wasn't checking Mutability and it
needs to because it supports fromRawData().
Change-Id: I3c7f9c85c83dfd02333762852fa456208e96d5ad
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This follows QArrayData::detachFlags's lead. Given the (known) size for
a detached container, the function helps determine capacity, ensuring
the capacityReserved flag is respected.
This further helps aggregating behaviour on detach in QArrayData itself.
SimpleVector was previously using qMax(capacity(), newSize), but there's
no reason to pin the previous capacity value if reserve() wasn't
requested. It now uses detachCapacity().
Change-Id: Ide2d99ea7ecd2cd98ae4c1aa397b4475d09c8485
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
I love how this magically makes SimpleVector move-aware :-)
Change-Id: I5cb75954d70cf256863c33e684ebc4551ac94f87
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
The macro was made empty in 4ecf82795d,
and is no longer necessary or used.
Change-Id: If000ff51729e41bdcd1b0409961cf94d50e5f172
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
- Updated copyright year, per 1fdfc2abfe
- Updated contact information, 629d6eda5c
- Drop "All rights reserved", 5635823e17
(Empty line added to maintain license header line count)
Change-Id: Ie401e2b6e40a4b79f4191377dd50dc60be801e1f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There isn't a good reason to impose the additional library call and
using the shared null here matches existing behavior in QByteArray,
QString and QVector.
Change-Id: Idd0bb9c7411db52630402534a11d87cbf2b1e7ba
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
This is done through a (POD) wrapper around a raw QTypedArrayData
pointer. The wrapper forces conscious decisions on the use of that
pointer, while implying it is internal API.
The pointed-to header is assumed to referenced, as if already owned by
the receiving QArrayDataPointer.
This wrapper is placed in the generic qarraydata.h header as its
definition doesn't depend on QArrayDataPointer by itself.
Change-Id: I9b2b6bb7dd9ab073dc7d882ccf999b32d793ed3f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The behavior of Q_CHECK_PTR is user-configurable. It may throw and
exception, output a warning or be a no-op. As such, its best used in
inline code that gets compiled into the user application.
Moving it out of the QArrayData API also enables this to be used in code
that must handle out-of-memory errors without crashing or otherwise
issuing warnings.
Putting in QArrayDataPointer gives good convenience coverage for those
who are implementing containers on top of the QArrayData stack, and
covers its use in the SimpleVector test case. It intentionally leaves
out the use of allocate to access the (hidden) shared-empties which
don't really allocate, anyway (in QArrayDataPointer::clear and
setSharable).
The autotest is not updated and will have to make do without the
Q_CHECK_PTR "protection". I think that is ok.
Change-Id: Idcad909903a9807866bf23ace89f1bf1edc53c3b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
By default, QTypedArrayData::fromRawData provides the same semantics as
already exist in QByteArray and QString (immutable, sharable data), but
more combinations are possible. In particular, immutable-unsharable
leaves the data owner in control of its lifetime by forcing deep copies.
As part of this, a new isMutable property is introduced in QArrayData.
This could be taken to be implicit in statics that are initialized with
a proper size but with alloc set to 0. QStringLiteral and QByteLiteral
already did this, forcing re-allocations on resize even before the
(static, thus shared) ref-count is considered.
The isMutable property detaches data mutability and shared status, which
are orthogonal concepts (at least in the unshared state). For the time
being, there is no API to explicitly (re)set mutability, but statics and
RawData mark data immutable.
Change-Id: I33a995a35e1c3d7a12391b1d7c36095aa28e221a
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This approach is better for future ABI evolution than using individual
bool parameters. QArrayData now also offers to calculate allocate
options for typical detach and clone operations: the CapacityReserved
flag is preserved, while cloning resets the Unsharable state.
Change-Id: I256e135adcf27a52a5c7d6130069c35c8b946bc3
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
They still exist and help avoid allocation of "empty" array headers, but
they're no longer part of the public API, thus reducing relocatable
symbols and relocations in inline code.
This means an extra non-inline call on QArrayDataPointer::clear and
setSharable operations, which are (expensive) detaching operations,
anyway.
Change-Id: Iea804e5ddc8af55ebc0951ca17a7a4e8401abc55
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Making use of the same feature added in RefCount.
To keep with the intention of avoiding the allocation of "empty" array
headers, this introduces an unsharable_empty, which allows users to
maintain the "unsharable bit" on empty containers, without imposing any
actual allocations.
(Before anyone asks, there is no point to a zero-sized capacity-reserved
container so no other combinations are needed for now.)
Change-Id: Icaa40ac3100ad954fdc20dee0c991861136a5b19
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
This class provides RAII functionality for handling QArrayData pointers.
Together with QArrayDataHeader and QArrayDataOps, this offers common
boilerplate code for implementing a container which, itself, defines its
own interface.
Change-Id: If38eba22fbe8f69038a06fff4acb50af434d229e
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Thiago Macieira
Lars Knoll
Marc Mutz
Allan Sandfeld Jensen
Liang Qi
Jani Heikkinen
Ulf Hermann
Matti Paaso
Sergio Ahumada
Iikka Eklund
João Abecasis