summaryrefslogtreecommitdiffstats
path: root/src/corelib/tools/qarraydata.cpp
Commit message (Collapse)AuthorAgeFilesLines
* QArrayData: remove AllocationResult and go back to output parameterThiago Macieira2025-08-051-22/+9
| | | | | | | | | | | The public API must have a single pointer return value because of limitations of GCC's __attribute__((malloc)), meaning we have no option but to have an output parameter for that too. Therefore, this simplifies the internals. Pick-to: 6.10 Change-Id: I0c12029a2f29fbbfd610fffd8d4931eca962b2e3 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QArrayData: fix potential UB in QBasicAtomic initializationMarc Mutz2025-07-041-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until C++17 (inclusive), a default-constructed std::atomic object can, officially, only be initialized with a call to std::atomic_init, for which QBasicAtomic doesn't have API. It is even unclear whether zero-initialization of static and thread-local objects will cause the object to be initialized. Seeing as we can't rely on malloc's zero-initialization to properly initialize std::atomic objects (and therefore QBasicAtomic ones), and because it's the right thing to do, from a [basic.life] POV, anyway, port to placement new instead. The realloc() feels fishy, seeing as it reallocs a struct that contains an atomic variable (which we don't mark as Q_RELOCATABLE_TYPE even for our own types), but assume that part it ok, and in-place construct only if realloc() was passed nullptr (so is equivalen to malloc()). A final solution for this can probably only be implemented when we can depend on C++20's atomic_ref, which decouples the underlying object from the atomic operations performed on it. Rename the ref_ member to m_ref to catch any uses of the variable, incl. since removed ones in older branches. Amends 812a611dc05e5facd036856625ccb9274fdcb117 (which ported from QtPrivate::RefCount to QBasicAtomicInt; I didn't check whether QtPrivate::RefCount had a similar problem, because that commit is already much older than what I can pick back to at this point). Task-number: QTBUG-137465 Pick-to: 6.10 6.9 6.8 6.5 Change-Id: I188e05d09e20e0820af7cf1cbb651afa860bb9d6 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add jemalloc supportAurélien Brooke2025-04-091-14/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Large graphical Qt applications heavily rely on heap allocations. Jemalloc is a general-purpose malloc(3) implementation designed to reduce heap fragmentation and improve scalability. It also provides extensive tuning options. Add a -jemalloc configure option, disabled by default. When enabled, Qt and user code link to jemalloc, overriding the system's default malloc(). Add cooperation with jemalloc for some Qt key classes: QArrayData (used by QByteArray, QString and QList<T>), QBindingStoragePrivate, QDataBuffer (used by the Qt Quick renderer), QDistanceFieldData, QImageData, QObjectPrivate::TaggedSignalVector, QVarLengthArray. This cooperation relies on two jemalloc-specific optimizations: 1. Efficient allocation via fittedMalloc(): Determine the actual allocation size using nallocx(), then adjust the container’s capacity to match. This minimizes future reallocations. Note: we round allocSize to a multiple of sizeof(T) to ensure that we can later recompute the exact allocation size during deallocation. 2. Optimized deallocation via sizedFree(): Use sdallocx(), which is faster than free when the allocation size is known, as it avoids internal size lookups. Adapt the QVarLengthArray auto tests on capacity. Non-standard functions docs are at https://jemalloc.net/jemalloc.3.html [ChangeLog][QtCore] Added optional support for the jemalloc allocator, and optimized memory allocations and deallocations in core Qt classes to cooperate with it. Change-Id: I6166e64e66876dee22662d3f3ea3e42a6647cfeb Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QArrayData: inline the allocateData functionAurélien Brooke2025-01-301-14/+5
| | | | | | | | | | | | It is already inlined by the compiler so this is a effectively a no-op. The aim of this change is to make later work in this file cleaner and easier to review. Deduplicate the if check and alloc assignment, and remove the unnecessary qsizetype cast. Change-Id: I139f1132779ce4c583a5be689800940801142d36 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QArrayData/Pointer: s/QPair/std::pair/Marc Mutz2023-12-131-3/+3
| | | | | | | | | | Also port from qMakePair to just braced initialization and CTAD. Task-number: QTBUG-115841 Pick-to: 6.7 Change-Id: Ifd7220ae88b101351e91d1488ce18715eb4880e5 Reviewed-by: Ahmad Samir <a.samirh78@gmail.com> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QArrayData: move AlignedQArrayData to the public headerThiago Macieira2023-12-111-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | This allows us to use it in QTypedArrayData<T>::AlignmentDummy, which is used in __builtin_assume_aligned() as a hint to the compiler. This increases the value we were passing as the compiler hint from 4 to 8 on 32-bit platforms and from 8 to 16 on 64-bit platforms. We actually do align to a bit higher than even that, but that's not an ABI guarantee we're making. However, it looks like GCC on 32-bit platforms is buggy, so we work around it. Commit r240248 ("Make max_align_t respect _Float128.", 63012d9a57edc950c5f30242d1e19318b5708060 in Git) increased std::max_align_t to 16 bytes on all platforms, saying "Such an increase is of course an ABI change" and "I think glibc malloc alignment should also increase to 16-byte 32-bit x86", but such a change to glibc was never implemented. Moreover, there are systems that don't use glibc, such as when using GCC on other OSes. This is not a change in Qt behavior anywhere. i386 does not (usually) do alignment checks, so most code wouldn't notice this at all. Pick-to: 6.7 Change-Id: I79e700614d034281bf55fffd178fa0aee2344307 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QArrayData: add allocate1 and allocate2 for 1- and 2-byte typesThiago Macieira2023-12-111-18/+46
| | | | | | | | | | | | | | | | This makes the two most-often used QTypedArrayData::allocate() -- the ones for char (for QByteArray) and char16_t (for QString) -- go to specialized versions, which have much simpler code. After all, multiplications by 1 are quite trivial. I didn't check whether an LTO compiler was const-propagating the sizes in inlined calls from qstring.cpp and qbytearray.cpp. But not everyone uses LTO, so this benefits everyone, in a very hot path, for minimal cost. Pick-to: 6.7 Change-Id: Ifa1111900d6945ea8e05fffd177dd1ce659b3fd5 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QArrayData: make calculateBlockSize() account for the extra null elementThiago Macieira2023-09-031-21/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of adding it after the block size was calculated. This makes no difference for non-growing (exact) blocks. For growing blocks, this means we take that extra element into account before rounding to the next power of two, instead of after. That results in a change of the thresholds of when a block grows and also what capacity it will contain. For example, for a QString growing to 22-25 elements: Request | Previously | Now | elements | bytes | malloc()ed | capacity() | malloc()ed | capacity() | 22 | 44 | 66 | 24 | 64 | 23 | 23 | 46 | 66 | 24 | 64 | 23 | 24 | 48 | 66 | 24 | 128 | 55 | 25 | 50 | 130 | 56 | 128 | 55 | To avoid wasting elementSize - 2 bytes in this footer, we only include this footer if elementSize <= 2. Thus, for a QList<int> growing to 11-13 elements: Request | Previously | Now | elements | bytes | malloc()ed | capacity() | malloc()ed | capacity() | 11 | 44 | 66 | 12 | 64 | 12 | 12 | 48 | 66 | 12 | 128 | 28 | 13 | 52 | 130 | 28 | 128 | 28 | In both cases, we now only allocate powers of two while growing, which may be beneficial to some allocators. Pick-to: 6.6 Change-Id: Ifa1111900d6945ea8e05fffd177dcb96e251d0a1 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* QArrayData: change calculateBlockSize() to not have an in/out parameterThiago Macieira2023-08-301-8/+10
| | | | | | | | Won't make a difference in codegen, but it's the right thing to do. Pick-to: 6.6 Change-Id: Ifa1111900d6945ea8e05fffd177dc8d200c2368f Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Replace {add,sub,mul}_overload with q{Add,Sub,Mul}OverloadMarc Mutz2023-06-121-3/+3
| | | | | | | | | | | | | | | | | | | These APIs started out as private APIs in qnumeric_p.h, but have since been made pseudo-public in qnumeric.h. The qnumeric_p.h versions just forward to the qnumeric.h ones, so just use the latter. This is in preparation of removing the {add,sub,mul}_overflow versions, which, despite being defined in the unnamed namespace, don't sport the q prefix, so potentially clash with global symbols. The change is a simple textual search and replace, manually excluding qnumeric_p.h. Picking to 6.5 to avoid cherry-pick conflicts going forward. Pick-to: 6.6 6.5 Change-Id: Ic0f7c92f7c47923317109e8a9dc06fa66bdff2c2 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Use SPDX license identifiersLucie Gérard2022-05-161-39/+3
| | | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Task-number: QTBUG-67283 Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* QArrayData: store the right flag type, not an intGiuseppe D'Angelo2021-05-171-1/+1
| | | | | | | | There's no reason to be storing `int` in the array data header and then using it as a QFlags. Just store the QFlags. Change-Id: I78f489550d74d15a560dacf338110d80a7ddfdd2 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Extend alignment of QArrayData to std::max_align_t in allocationAndrei Golubev2021-01-261-7/+16
| | | | | | | | | | | | | | | | | | | | Make stricter alignment requirements for the allocated header This strict alignment allows reallocateUnaligned() to property account for the padding occurring in cases when alignof(QArrayData) < alignof(T) <= alignof(std::max_align_t), which happens to be the case on e.g. 32-bit platforms with specific alignment requirements. This adds 4 bytes (the difference between alignof(std::max_align_t) and sizeof(QArrayData)) of overhead for QString, QByteArray and certain QLists on 32-bit systems. Task-number: QTBUG-90359 Pick-to: 6.0 Change-Id: I8176a4cc79f100ee772b09425e88fe8ff3ae226a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* QString/QByteArray: add missing Q_CHECK_PTRThiago Macieira2020-12-041-0/+3
| | | | | | | | | | | | | | So these two classes throw when trying to allocate silly sizes or in OOM conditions. We probably want to move these Q_CHECK_POINTER into QTypedArrayData but I didn't want to do that in this commit. Task-number: QTBUG-88256 Task-number: QTBUG-88253 Change-Id: Ifc61bb80b9bf48a386abfffd1648176111770174 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Clean realloc() related bits in QString/QBA and Q*ArrayOpsAndrei Golubev2020-11-121-3/+6
| | | | | | | | | | | | | | | Fixed misleading naming of "slowReallocatePath". It's no longer "slow", it's downright dangerous now to reallocate under certain conditions Added several asserts which should've been there already as our code would run into a UB/crash anyhow - let's at least get extra checks that are closer to the trouble causing places Bring back the (slightly modified) code-cleaning changes from 504972f838761f79a170c22225add496e7e5af6a Change-Id: Ie1358aebc619062d3991a78049e366dc0e8c267e Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Revert "Refine {QString, QBA}::reallocData() logic"Volker Hilsheimer2020-11-081-6/+3
| | | | | | | | | | This reverts commit 504972f838761f79a170c22225add496e7e5af6a. Introduced realloc failures in qdoc. Task-number: QTBUG-88258 Change-Id: I953e8d3933085022c75068af357ec9a44ab7e984 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Refine {QString, QBA}::reallocData() logicAndrei Golubev2020-11-061-3/+6
| | | | | | | | | | | | Fixed misleading naming of "slowReallocatePath". It's no longer "slow", it's downright dangerous now to reallocate under certain conditions While at it, added extra assert to QArrayData::reallocateUnaligned() and cleaned up that function a bit Change-Id: I05921fb5058eb563997e66107566c87fb4ea5599 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Introduce QADP::reallocateGrow()Andrei Golubev2020-11-041-0/+3
| | | | | | | | | | | | | | Added realloc() code path to QMovableArrayOps Implemented fast realloc() based growing for QADP and used it in QList::emplaceBack. This gives quite a bit of speedup and shows better results than 5.15 at 100k+ iterations of "list.append(elem)", meanwhile also closing a gap between movable types Task-number: QTBUG-87330 Change-Id: I42fc182ecd93c85600dac622385152fc57735da8 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Clean up out allocation handlingLars Knoll2020-11-041-3/+2
| | | | | | | | | | Get rid of the allocation options inside the flags field of QArrayData, they are really a completely separate thing. Change-Id: I823750ab9e4ca85642a0bd0e471ee79c9cde43fb Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Cleanup QArrayDataOps::reallocate() and relatedLars Knoll2020-11-041-9/+9
| | | | | | | | | | Don't use QArrayData::GrowsForward/Backward anymore and replace it with a simple 'bool grow'. Change-Id: Ifddfef3ae860b11dda4c40854c71ef2aeb29df34 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Reserve extra space for '\0' in QArrayData::allocateAndrei Golubev2020-08-291-0/+30
| | | | | | | | | | | Added implicit space reservation for '\0' in allocation functions used by containers. In current setting, this means sizeof(char16_t) bytes extra memory is allocated each time and implicitly exists. The extra memory is uninitialized by default Task-number: QTBUG-84320 Change-Id: Ia3cc268183c00ea24ea9d326db3f392f71868d52 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Support GrowsBackwards flag in QArrayDataPointerAndrei Golubev2020-08-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Introduced allocation function in QArrayDataPointer with interface similar to QArrayData::allocate that supports growing strategies. This func is used instead of the original in cases when prepend-aware storage is needed. Tried to follow Qt5 QList policy in terms of space reservation Updated QPodArrayOps::reallocate to be aware of growing shenanigans. It doesn't look like a perfect solution but it is rather close and similar to what Qt6 QList is doing when not growing (e.g. reserve/squeeze) Added initial QCommonArrayOps with helper function that tells when reallocation is preferable over just using the insert-like operation. This comes up later on when GrowsBackwards policy is properly supported in operations Essentially, 2/3 main data management blocks for prepend optimization are introduced here. The last one being a generalized data move that is done instead of reallocation when existing free space is not enough Task-number: QTBUG-84320 Change-Id: I9a2bac62ad600613a6d7c5348325e0e54aadb73d Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add QArrayDataPointer::freeSpace*() functionsAndrei Golubev2020-08-181-5/+4
| | | | | | | | | | | | | Added functions that tell how much free space is available at the beginning and at the end of the storage Updated preconditions of operations to use freeSpace* functions Also, changed casts uint(this->size) to size_t(this->size) Task-number: QTBUG-84320 Change-Id: Iad94c1060a00f62068da9d1327e332a00d4f4109 Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Allow allocating more than 2G items in a vectorLars Knoll2020-07-061-50/+42
| | | | | | | | | | | Also adjust qCalculateBlockSize() to be able to handle large allocations. QVector::length() is currently still limited to 2G items, that will get changed in a later commit. Change-Id: I3a92fbfd7f281d30844c5fafa3b9a474bc347c19 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Get rid of QArrayData::sharedNull()Lars Knoll2020-07-061-22/+3
| | | | | | | | Remove the last places where those got used and avoid allocations when we resize to 0. Change-Id: Ib553f4e7ce7cc24c31da15a55a86d18bdf1cc5c3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Get rid of unused flags in QArrayDataLars Knoll2020-07-061-7/+2
| | | | | Change-Id: I3ea754b44fb33e33baba0781d9ae15b7f3b3d8eb Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Get rid of shared null for QByteArray, QString and QVectorLars Knoll2020-07-061-12/+2
| | | | | | | | | | | | | | As a side effect, data() can now return a nullptr. This has the potential to cause crashes in existig code. To work around this, return an empty string from QString::data() and QByteArray::data() for now. For Qt 6 (and once all our internal issues are fixed), data() will by default return a nullptr for a null QString, but we'll offer a #define to enable backwards compatible behavior. Change-Id: I4f66d97ff1dce3eb99a239f1eab9106fa9b1741a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Only use one macro per lineLars Schmertmann2020-07-031-1/+2
| | | | | | | | | Also add a ; where it is missing. Task-number: QTBUG-82978 Change-Id: Ic5d2a07363c25ab641d234baca89bc62238458cb Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Small cleanupLars Knoll2020-07-021-9/+2
| | | | | | Change-Id: Ic8ed50a05a9723ed252f0762d86e41fe719fc3ef Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Ensure left/right/mid behave in a compatible wayLars Knoll2020-06-091-29/+0
| | | | | | | | | | | | | | | | | | | | QString and QStringRef did bounds checking for left/right/mid, whereas QStringView was asserting on out of bounds. Relax the behavior for QStringView and do bounds checking on pos/n as well. This removes a source of potentially hidden errors when porting from QStringRef (or QString) to QStringView. Unfortunately, one difference remains, where QByteArray::left/right() behaves differently (and somewhat more sane) than QString and QStringRef. We're keeping the difference here, as it has been around for many years. Mark left/right/mid as obsolete and to be replaced with the new first/last/slice methods. Change-Id: I18c203799ba78c928a4610a6038089f27696c22e Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* MSVC: Fix integer conversion warnings in containersFriedemann Kleint2020-01-031-2/+2
| | | | | | | | | | | | Add some casts, fixing warnings like: src/corelib/text/qbytearray.h(490): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data src/corelib/text/qstring.h(1045): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data src/corelib/tools/qarraydatapointer.h(80): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data src/corelib/tools/qarraydatapointer.h(75): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data src/corelib/text/qbytearray.h(490): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data Change-Id: I221db4d5b660224f0fc1869248802c496db1b91c Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Merge remote-tracking branch 'origin/5.15' into devQt Forward Merge Bot2019-12-091-1/+1
|\ | | | | | | Change-Id: Ia24cc8b86def0d9d9c17d6775cc519e491b860b1
| * Tidy nullptr usageAllan Sandfeld Jensen2019-12-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | Move away from using 0 as pointer literal. Done using clang-tidy. This is not complete as run-clang-tidy can't handle all of qtbase in one go. Change-Id: I1076a21f32aac0dab078af6f175f7508145eece0 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* | Use QArrayDataPointer to implement QByteArrayLars Knoll2019-12-081-0/+1
| | | | | | | | | | Change-Id: I2ee28023c2dea9fc3160400112c59a47566a4868 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Final removal of the size and offset members from QArrayDataThiago Macieira2019-12-081-4/+2
| | | | | | | | | | | | | | | | Those members are not required anymore and now part of the object itself. Change-Id: If9eb5355ca8f2cf9528f6f63ca4e172acc9f9aed Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Start moving QArrayData's size and data pointer to the main classThiago Macieira2019-12-081-10/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Stop using the reference counter to store data stateThiago Macieira2019-12-081-6/+7
| | | | | | | | | | | | | | | | | | | | | | Instead of using the reference count to store whether the data is sharable and whether the header is immutable, move the settings to the flags member. This allows us to save one comparison per deref() or needsDetach(). It also allows for the possibility of mutable data pointed to by a static header. Change-Id: Ie678a2ff2bb9bce73497cb6138b431c465b0f3bb Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Add reference-count manipulation functions to QArrayData and hide refThiago Macieira2019-12-081-3/+3
| | | | | | | | | | | | | | | | 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>
* | Introduce the Mutable flag and move QArrayDataPointer::needsDetachThiago Macieira2019-12-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Introduce flags to indicate the QArrayData typeThiago Macieira2019-12-071-20/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These flags allow us to determine what type of data QArrayData is carrying. There are currently only two supported types: - raw data type: constructed via fromRawData or static data - allocated data type: regular data done via heap allocation The QArrayData object is usually allocated on the heap, unless its own reference count is -1 (indicating static const QArrayData). Such object should have a type of RawDataType, since we can't call free(). Add GrowsBackward for completeness as well as the StaticDataFlags default for static data. Change-Id: Icc915a468a2acf2eae91a94e82451f852d382c92 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Replace QArrayData::capacityReserved with a full flags fieldThiago Macieira2019-12-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Instead of stealing one bit from the alloc field, let's use a full 32-bit for the flags. The first flag to be in the field is the CapacityReserved (even though the allocate() function will store some others there, not relevant for now). This is done in preparation for the need for more flags necessary anyway. Change-Id: I4c997d14743495e0d4558a6fb0a6042eb3d4975d Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Rename QArrayData::AllocateOptions enum and update some flagsThiago Macieira2019-12-071-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Get rid of unsharable containersLars Knoll2019-10-301-17/+1
| | | | | | | | | | | | | | | | 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>
* | Replace Q_ALIGNOF usage in qtbase with C++11 alignof keywordVolker Hilsheimer2019-10-291-4/+4
|/ | | | | | | | | | | | | | | | The macro is not documented, so not part of the public Qt API. It is made obsolete by the alignof keyword in C++11. Remove the usage of the macro across qtbase, in particular the workarounds for compilers that didn't support alignof, and that will not be supported in Qt 6. The macro definition is left in place, no need to break existing code. Task-number: QTBUG-76414 Change-Id: I1cfedcd4dd748128696cdfb546d97aae4f98c3da Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* QArrayData: Don't allocate space we cannot useMårten Nordheim2019-08-301-1/+1
| | | | | | | | | | | | | When reallocating we assume we will grow more and increase the size to the next power of 2. However, this might be a size where we end up with space we cannot take advantage of. Such as having 4 bytes free at the tail when we have 8 byte objects. The larger the objects are the greater the chance is that we will end up in this situation, and it would have a greater chance to leave big allocated chunks unused. Change-Id: Ifea3d92763c1bafd489b66605c741447e5a57d5a Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Port from QAtomic::load() to loadRelaxed()Giuseppe D'Angelo2019-06-201-2/+2
| | | | | | | | | | | | | | | Semi-automated, just needed ~20 manual fixes: $ find \( -iname \*.cpp -or -iname \*.h \) -exec perl -pe 's/(\.|->)load\(\)/$1loadRelaxed\(\)/g' -i \{\} + $ find \( -iname \*.cpp -or -iname \*.h \) -exec perl -pe 's/(\.|->)store\(/$1storeRelaxed\(/g' -i \{\} + It can be easily improved (e.g. for store check that there are no commas after the opening parens). The most common offender is QLibrary::load, and some code using std::atomic directly. Change-Id: I07c38a3c8ed32c924ef4999e85c7e45cf48f0f6c Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
* Move away from using 0 as a pointer constantAllan Sandfeld Jensen2019-06-071-1/+1
| | | | | | | | | Cleans up most of corelib to use nullptr or default enums where appropriate. Change-Id: Ifcaac14ecdaaee730f87f10941db3ce407d71ef9 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Move container block-size calculations to qarraydata.cppEdward Welbourne2019-05-291-1/+104
| | | | | | | | | | | | | | These were in qbytearray.cpp, which doesn't use them, is big and I intend to move it to a different directory than the header, qtools_p.h, that declares them. So move them to a small file that does use them. Change-Id: I5a4684f8c7628e617546019cc3f01d92d829f085 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Replace Q_DECL_NOEXCEPT with noexcept in corelibAllan Sandfeld Jensen2019-04-031-3/+3
| | | | | | | In preparation of Qt6 move away from pre-C++11 macros. Change-Id: I44126693c20c18eca5620caab4f7e746218e0ce3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix can not -> cannotRobert Loehning2019-02-251-1/+1
| | | | | Change-Id: Ie9992f67ca59aff662a4be046ace08640e7c2714 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2025-11-24 23:47:25 +0000