, as those are going away.
This cleans use of those operations in the QArrayData stack.
Change-Id: I67705fe0a2f8d99ea13739b675021356a5736f83
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
Reviewed-by: hjk <qthjk@ovi.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 is only for a test case, but still...)
Change-Id: Ied205860e5469000249e15a5478c10db53f1fdaa
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@nokia.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 removes const qualification on data members of QConst*Data, which
was subjecting QString's and QByteArray's shared_null to the "order of
static initialization fiasco", with up-to-date VS 2010.
Furthermore, the const qualification in the places where it was removed
had little meaning and no value. It was unnecessary. As such, "Const"
was removed from the struct's names and "Static" used in its place, to
imply their usefulness in supporting statically-initialized fixed-size
(string and byte) containers.
A test case was added to QArrayData as that is meant to replace both
QStringData and QByteArrayData in the near future.
VS issue reported at:
https://connect.microsoft.com/VisualStudio/feedback/details/716461
Change-Id: I3d86f2a387a68f359bb3d8f4d10cf3da51c6ecf7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
A reference count of 0 (zero) would never change. RefCount::deref to
zero would return false (resource should be freed), subsequent calls on
the same state would return true and not change state. While safe from
RefCount's side, calling deref on a reference count of zero potentially
indicated a dangling reference.
With this change, a reference count of 0 is now abused to imply a
non-sharable instance (cf. QVector::setSharable). This instance is to be
deleted upon deref(), as the data is not shared and has a single owner.
In practice, this means an (intentional) change in behaviour in that
deref'ing zero still won't change state, but will return false, turning
previous access to dangling references into double free errors.
Users of RefCount wanting to support non-sharable instances are required
to check the return of RefCount::ref() and use RefCount::isShared() to
determine whether to detach (instead of directly checking count == 1).
New functions are introduced to determine whether RefCount indicates a
"Static" (permanent, typically read-only) or "Sharable" instance and
whether the instance is currently "Shared" and requires detaching prior
to accepting modifications..
This change formalizes -1 as the value used to flag persistent,
read-only instances, no longer reserving the full negative domain. The
concrete value is part of the ABI, but not of the API. (isStatic and
Q_REFCOUNT_INITIALIZE_STATIC are part of the API, instead)
Change-Id: I9a63c844155319bef0411e02b47f9d92476afefe
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
This was only being used to initialize static read-only RefCount
instances, where the value is hard-wired to -1. Instead of allowing
initialization with arbitrary values (which for a reference count can be
error prone) the intent of the macro is made explicit with its
replacement Q_REFCOUNT_INITIALIZE_STATIC.
Change-Id: I5b0f3f1eb58c3d010e49e9259ff4d06cbab2fd35
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@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>
Inserting elements anywhere in the array requires moving the elements
that follow out of the way and writing in the new ones. Trivial for PODs
and almost as much for movable types.
For "complex" types, we start by extending the array with placement new
and copy constructing elements. Then, copy assignment resets the
elements that were previously part of the array.
QPodArrayOps uses non-throwing operations. QMovableArrayOps provides
full rollback in the face of exceptions (strong guarantee).
QGenericArrayOps enforces that no data is leaked (all destructors
called) and invariants are maintained on exceptions -- the basic
guarantee.
With 3 different implementations, 2 of which are non-trivial, this
operation is a good showcase for QArrayOpsSelector and the different
implementations. As such, it warrants its own commit.
Change-Id: I21d9b4cb8e810db82623bcd1d78f583ebf3b6cb7
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
This class, the selector and underlying implementations provide
specialized operations on QArrayData, while allowing for optimized
implementations that benefit from type-specific information.
Currently, offering a generic implementation and specializations for
PODs (trivial ctor, dtor and move operations) and movable types (can be
trivially moved in memory).
Change-Id: I2c5829b66c2aea79f12f21debe5c01f7104c7ea3
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
A bug has been reported against GCC 4.4.3 (present in other version as
well), where the use of an array of size 1 to implement dynamic arrays
(such as QVector) leads to incorrect results in optimized builds as the
compiler assumes the index to be 0.
This test tries to ensure QArrayDataHeader is not affected by this bug,
as QVector currently is.
Change-Id: Id701496bae4d74170de43399c1062da40eb078e7
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
QTypedArrayData is a typed overlay for QArrayData, providing convenience
and type-safety. It adds no data members to QArrayData, thus avoiding
compiler-generated warnings for aliasing issues when casting back and
forth.
Change-Id: I969342a30989c4c14b3d03d0602e3d60a4cc0e9d
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
Centralizing QArrayData memory management decisions in one place will
allow us to be smarter in how we allocate header and data.
At the moment, these are allocated as a single block. In the future we
may decide to allocate them separately for "large" data or specific
alignment requirements.
For users of QArrayData this remains transparent and not part of the
ABI. The offset field in QArrayDataHeader enables this.
This also hard-wires allocation of empty arrays to return shared_empty.
Allocating detached headers (e.g., to support fromRawData) will thus
require explicit support.
Change-Id: Icac5a1f51ee7e468c76b4493d29debc18780e5dc
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
SimpleVector is meant solely as a test case and reference container
implementation based on QArrayData functionality.
It shall not replace QVector or friends.
Change-Id: I5c66777c720f252c8e073a2884c6d5f1ac836d0e
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Modeled on QByteArrayData/QStringData/QVectorData, the intent is to
unify book-keeping structs for array-like data and enable sharing of
code among them.
As in those structures, size (and alloc) data member(s) specify the
number of *typed* elements the array does (and can) hold. The size or
alignment requirements of those objects is not tracked in this data
structure and needs to be maintained by its users.
Contrary to QByteArrayData and QStringData, QArrayData's offset member
keeps a *byte* offset to the actual data array and is computed from the
beginning of the struct.
Shared-null and -empty functionality is provided by QArrayData and
shared among all users.
Planned features include setSharable (force deep copies), fromRawData
(detached header and data allocations) and literals a la QStringLiteral
(static immutable instances), thus covering the functionality needed for
QByteArray, QString and QVector.
Change-Id: I9aa709dbb675442e6d06965efb8138ab84602bbd
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
