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>
