summaryrefslogtreecommitdiffstats
path: root/tests/auto/corelib/tools/qarraydata
Commit message (Collapse)AuthorAgeFilesLines
* Introduce QArrayDataPointer::needsDetachJoão Abecasis2012-04-021-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Introduce QArrayDataOps::truncateJoão Abecasis2012-04-022-2/+95
| | | | | | | | | | | | | | This enables a truncating resize() to be implemented. It is similar to destroyAll(), but updates the size() as it goes, so it is safe to use outside a container's destructor (and doesn't necessarily destroy all elements). The appendInitialize test was repurposed and now doubles as an additional test for QArrayDataOps as well as exercising SimpleVector's resize(). Change-Id: Iee94a685c9ea436c6af5b1b77486734a38c49ca1 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Introduce QArrayData::detachCapacityJoão Abecasis2012-04-022-7/+13
| | | | | | | | | | | | | | | 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>
* Introduce QArrayDataOps::appendInitializeJoão Abecasis2012-04-022-1/+80
| | | | | | | | | | | | | Adds given number of default-initialized elements at end of array. For POD types, initialization is reduced to a single memset call. Other types get default constructed in place. As part of adding a test for the new functionality the arrayOps test was extended to verify objects are being constructed and assigned as desired. Change-Id: I9fb2afe0d92667e76993313fcd370fe129d72b90 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Make QArrayData::shared_null zero terminated.Jędrzej Nowacki2012-03-291-4/+4
| | | | | | | This is expected by QByteArray and QString Change-Id: Ib668b144bdc0d2c793018c8f8d794f249eaf935c Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
* Fix invalid read, detected by valgrindJoão Abecasis2012-03-151-10/+10
| | | | | | | | | | | | | | | | | Commit 3fe1eed0 changed the QVERIFY in line 1354 to QCOMPARE. This was done to work around a (not yet understood) compiler issue. That however was wrong, as char pointers in QCOMPARE are assumed to point to '\0'-terminated strings and will get dereferenced. In this case the intent was to compare the actual pointer values, as the pointers point past the end of the array and should not be dereferenced. Explicitly casting to (void *) and using QCOMPARE will not only keep the intent, it will hopefully also provide meaningful output on failures. As such the fix was applied throughout the test. Change-Id: Ib0968df492ccc11d7c391bb69037cd7241e55493 Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
* Silence 'narrowing conversion' warning in testJoão Abecasis2012-03-131-1/+1
| | | | | | | | | | | Seen with gcc 4.6: tst_qarraydata.cpp: In member function 'void tst_QArrayData::grow()': tst_qarraydata.cpp:1445:29: error: narrowing conversion of 'i' from 'size_t {aka long unsigned int}' to 'int' inside { } [-fpermissive] Change-Id: Iad55659554b64ee34655640d606153f058a8cd05 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Skip test when implicit move operators not availableJoão Abecasis2012-03-081-0/+43
| | | | | | | | | | | | | Besides rvalue-references, this test depends on the compiler to generate implicit move operators on a derived class, based on the ones available on its base class. At least Visual Studio 2010 and some variations of clang 3.0 are known not to generate implicit move constructors and assignment operators. Gcc 4.6 and up seem to support the feature. Change-Id: Ied464ef678f517321b19f8a7bacddb6cd6665585 Reviewed-by: Kent Hansen <kent.hansen@nokia.com>
* Add AllocationOption::GrowJoão Abecasis2012-02-292-4/+36
| | | | | | | | | | | | | | | | | | | | | | | This is meant to reduce the number of allocations on growing containers. It serves the same purpose as the existing qAllocMore which is currently used by container classes. While only a container knows when it is growing, it doesn't need to care how that information is used. qAllocMore is currently treated as a black-box and its result is (basically) forwarded blindly to an allocate function. In that respect, container code using qAllocMore acts as an intermediary. By merging that functionality in the allocate function itself we offer the same benefits without the intermediaries, allowing for simpler code and centralized decisions on memory allocation. Once all users of qAllocMore get ported to QArrayData and QArrayData::allocate, qAllocMore can be moved or more closely integrated into qarraydata.cpp and qtools_p.h can be dropped. Change-Id: I4c09bf7df274b45c399082fc7113a18e4641c5f0 Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
* Test setSharable with "raw data"João Abecasis2012-02-291-0/+3
| | | | | Change-Id: I91774685e84416407aa1fa136f27fedb82545a12 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* SimpleVector: don't assert when reserving on emptyJoão Abecasis2012-02-222-2/+65
| | | | | Change-Id: I09ac235085e645c8149c153653377252fef6fa3d Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Workaround compiler issueJoão Abecasis2012-02-221-1/+1
| | | | | | | | | | | | I can't figure this one out, but it seems to be a clang compiler bug that is triggered in association with -DQT_NO_DEBUG. Changing the test from QVERIFY to QCOMPARE keeps the intent and the check, but makes the failure go away. It can't hurt... Change-Id: Ib34e5e850e5b731d729e417430dec55e372805ac Reviewed-by: Chris Adams <christopher.adams@nokia.com>
* Add support for rvalue-references in QArrayDataPointerJoão Abecasis2012-02-131-0/+46
| | | | | | | I love how this magically makes SimpleVector move-aware :-) Change-Id: I5cb75954d70cf256863c33e684ebc4551ac94f87 Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
* Update license headersJoão Abecasis2012-02-062-6/+6
| | | | | | | | | | | - Updated copyright year, per 1fdfc2abfe1fa26b86028934d4853432e25b4655 - Updated contact information, 629d6eda5cf67122776981de9073857bbc3dcba2 - Drop "All rights reserved", 5635823e17db3395d9b0fa8cfcc72f82fea583f4 (Empty line added to maintain license header line count) Change-Id: Ie401e2b6e40a4b79f4191377dd50dc60be801e1f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Make clear() use the shared null inlineJoão Abecasis2012-02-011-2/+2
| | | | | | | | | 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>
* Fix some warnings with ClangJoão Abecasis2012-01-261-3/+3
| | | | | | | | | | | | The extra bool arguments weren't needed in the first place as they specify the default, but were left behind when allocate parameters were changed from bools to AllocationOptions. Clang saves the day by pointing out the weird conversion going through void ** (!?) Change-Id: Ia0dafce06bf0ee62bd825a2db819c890343b6342 Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
* Introducing Q_ARRAY_LITERALJoão Abecasis2012-01-252-0/+97
| | | | | | | | | | | | | | | | | | | This provides the same functionality as the specialized QStringLiteral and QByteArrayLiteral, but on top of QArrayData. The macro has two variations, variadic and simple. The variadic version depends on compiler support for (C99) variadic macros and enables static initialization of arrays of any POD data. Use of this macro is not recommended on code or applications that need to work in configurations where variadic macros are not supported. The simple version is more portable and is enough to support the use cases of QStringLiteral and QByteArrayLiteral, also providing a fallback that allocates and copies data when static initialization is not available. Change-Id: I7154a24dcae4bbbd7d5978653f620138467830c5 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Don't use RefCount int operationsJoão Abecasis2012-01-171-18/+18
| | | | | | | | | | , 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>
* Rename QArrayData::AllocateOption to AllocationOptionJoão Abecasis2012-01-162-7/+7
| | | | | Change-Id: Id3e7c748b4b40d703ad1785c903c96bdd968390e Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
* Enable QArrayData to reference external array dataJoão Abecasis2012-01-162-0/+57
| | | | | | | | | | | | | | | | | | | | | | 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>
* Expand if condition for readabilityJoão Abecasis2012-01-111-8/+15
| | | | | Change-Id: I5057c236457587ad03b55019cb340cf59d9ecdb5 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Don't allocate when inserting overlapping dataJoão Abecasis2012-01-111-3/+7
| | | | | | | | (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>
* Add setSharable support to SimpleVectorJoão Abecasis2012-01-102-4/+79
| | | | | Change-Id: I606064d86b58be1a6a57f64f4eb55a4a751a0811 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add AllocateOptions to QArrayDataJoão Abecasis2012-01-092-20/+34
| | | | | | | | | | 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>
* Remove shared_empty and unsharable_empty from APIJoão Abecasis2012-01-061-6/+12
| | | | | | | | | | | | | | 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>
* Add setSharable support in QArrayData stackJoão Abecasis2012-01-061-6/+146
| | | | | | | | | | | | | | | 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>
* Adding detach to QArrayDataPointerJoão Abecasis2012-01-062-6/+56
| | | | | | | | Detaching operations added to SimpleVector Change-Id: I5f549582cf579569f08cb8d53a6d12fe32b862e6 Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Ensure shared_null(s) are statically initialized on VS 2010João Abecasis2012-01-051-0/+17
| | | | | | | | | | | | | | | | | | | | | | | 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>
* Add support for setSharable in RefCountJoão Abecasis2012-01-052-5/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Retire the generic Q_REFCOUNT_INITIALIZER macroJoão Abecasis2012-01-041-3/+3
| | | | | | | | | | | | | 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>
* Introducing QArrayDataPointerJoão Abecasis2011-12-141-42/+18
| | | | | | | | | | | 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>
* QArrayDataOps::insertJoão Abecasis2011-12-142-0/+238
| | | | | | | | | | | | | | | | | | | | | | | 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>
* QArrayDataOps: generic array operationsJoão Abecasis2011-12-142-7/+140
| | | | | | | | | | | | | 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>
* Add test for GCC bug #43247João Abecasis2011-12-111-0/+28
| | | | | | | | | | | | | | 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>
* template<class T> struct QTypedArrayDataJoão Abecasis2011-12-112-15/+152
| | | | | | | | | | 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>
* Allocate/free support in QArrayDataJoão Abecasis2011-12-091-0/+144
| | | | | | | | | | | | | | | | | | | 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 as a test case for QArrayDataJoão Abecasis2011-12-073-0/+289
| | | | | | | | | | 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>
* Introducing QArrayDataJoão Abecasis2011-12-062-0/+156
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-01 20:21:35 +0000