summaryrefslogtreecommitdiffstats
path: root/src/corelib/tools/qarraydata.h
Commit message (Collapse)AuthorAgeFilesLines
* Replace Q_NULLPTR with nullptr where possibleKevin Funk2017-09-191-2/+2
| | | | | | | | | | | | | Remaining uses of Q_NULLPTR are in: src/corelib/global/qcompilerdetection.h (definition and documentation of Q_NULLPTR) tests/manual/qcursor/qcursorhighdpi/main.cpp (a test executable compilable both under Qt4 and Qt5) Change-Id: If6b074d91486e9b784138f4514f5c6d072acda9a Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
* Move Q_REQUIRED_RESULT to its correct positionThiago Macieira2017-04-201-8/+6
| | | | | | | | | | | 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>
* Add QArrayData::reallocateUnaligned for QString and QByteArrayThiago Macieira2016-09-071-0/+11
| | | | | | | | | | | | | | | | | | | This function reallocates a QArrayData block with realloc() but, as the name says, it's only valid for types that do not increase the alignment requirements. I don't think it's worth doing this for types that do increase the alignment requirements, since we don't know the alignment of the pointer returned by realloc(). If the new pointer modulo the alignment is different from the old pointer modulo the alignment, we'd have to memmove data around, which would be quite inefficient (realloc might have memcpy'ed already and this memmove would copy data to nearby). This function is intended to be used especially in QString and QByteArray, which were already using realloc() on pointers created by QArrayData::allocate. Change-Id: I45b61247db2e84797ad794c1049c47a09c1fb29a Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
* Merge remote-tracking branch 'origin/5.6' into 5.7Liang Qi2016-05-191-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: configure src/3rdparty/angle/src/libANGLE/renderer/d3d/d3d11/Renderer11.cpp src/network/access/qnetworkaccessmanager.cpp src/plugins/platforms/cocoa/qcocoacolordialoghelper.mm src/plugins/platforms/eglfs/deviceintegration/eglfs_kms/qeglfskmsgbmcursor.cpp src/plugins/platforms/eglfs/deviceintegration/eglfs_kms/qeglfskmsgbmcursor.h src/widgets/widgets/qlineedit_p.cpp src/widgets/widgets/qlineedit_p.h src/winmain/winmain.pro tests/auto/corelib/io/qstorageinfo/tst_qstorageinfo.cpp tests/auto/dbus/qdbusconnection/tst_qdbusconnection.cpp tests/auto/dbus/qdbusconnection/tst_qdbusconnection.h tests/auto/testlib/selftests/expected_cmptest.teamcity tests/auto/testlib/selftests/expected_cmptest.txt tests/auto/widgets/itemviews/qtableview/tst_qtableview.cpp tools/configure/configureapp.cpp Change-Id: Ib9997b0d0f91946e4081d36c0c6b696c5c983b2a
| * Fix Clang -Wexpansion-to-defined warning by deprecating QT_SUPPORTSThiago Macieira2016-05-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Updated license headersJani Heikkinen2016-01-151-14/+20
|/ | | | | | | | | | | 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>
* Compile with !QT_SUPPORTS(UNSHARABLE_CONTAINERS)Marc Mutz2015-07-081-0/+2
| | | | | | | 'Unsharable' isn't available, then. Change-Id: Ifab3b2306379c651bfcd8381836a8f7eadbdc6d6 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QtCore: Use Q_NULLPTR instead of 0 in all public headersMarc Mutz2015-07-011-2/+2
| | | | | | | | | This is in preparation of adding -Wzero-as-null-pointer-constant (or similar) to the headers check. Task-number: QTBUG-45291 Change-Id: I0cc388ef9faf45cbcf425ad0dc77db3060c104a8 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Update copyright headersJani Heikkinen2015-02-111-7/+7
| | | | | | | | | | | | | | | | | | 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>
* QtCore: mark some operations nothrowMarc Mutz2015-01-101-2/+2
| | | | | | | | | | | | This shotgun-surgery approach is motivated by trying to get a clean(er) build for -Wnoexcept on GCC, so it is expected that for any class touched here, there will be more operations that can be marked nothrow. But they don't show up in conditional noexcept clauses, yet, so they are deferred to some later commit. Change-Id: I0eb10d75a26c361fb22cf785399e83b434bdf233 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Update license headers and add new license filesMatti Paaso2014-09-241-19/+11
| | | | | | | | | - Renamed LICENSE.LGPL to LICENSE.LGPLv21 - Added LICENSE.LGPLv3 - Removed LICENSE.GPL Change-Id: Iec3406e3eb3f133be549092015cefe33d259a3f2 Reviewed-by: Iikka Eklund <iikka.eklund@digia.com>
* Don't track the sharable bit upon detachJoão Abecasis2014-07-281-4/+0
| | | | | | | | | | "Unsharables", given they can't be shared, don't need to detach, so skip the check altogether and don't try to propagate the flag. It shouldn't be. Change-Id: Icc483401d5a57708b43d64bd3cebc66c6b934815 Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Unify all mid() functions in QtBase.Jędrzej Nowacki2014-05-161-0/+8
| | | | | | | | | | | | | | | | | | | Up to now, Qt had at least 3 different implementations of the mid(). Only QString::mid implementation was not crashing on edge cases and was protected against overflows, therefore I picked that one as the base implementation, even if it has weird semantics for an invalid input. As a side effect QVector::mid was slightly optimized to not detach in all cases (which follows current QList behavior). Documentation of QVector::mid and QList::mid was updated to not mention "copy of data" which could suggest that the mid() result is detached. QStringRef::mid was fixed and now it follows general Qt behavior, by returning a null value for a null input. Change-Id: Ie9ff5d98372bd193d66508e6dd92b6ed1180ad9b Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Merge remote-tracking branch 'origin/stable' into devFrederik Gladhorn2014-05-061-0/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: mkspecs/qnx-x86-qcc/qplatformdefs.h src/corelib/global/qglobal.h src/opengl/gl2paintengineex/qpaintengineex_opengl2.cpp src/opengl/qgl.cpp src/opengl/qglpixelbuffer.cpp src/opengl/qglshaderprogram.cpp tests/auto/opengl/qglthreads/tst_qglthreads.cpp Change-Id: Iaba137884d3526a139000ca26fee02bb27b5cdb5
| * Deprecate setSharable in Qt containersThiago Macieira2014-04-241-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'origin/stable' into devSimon Hausmann2014-02-281-2/+2
|\| | | | | | | | | | | | | Conflicts: src/network/access/qhttpthreaddelegate.cpp Change-Id: Ia15372687c93cd585967b006c0baaac3a5f29e91
| * Make sure all containers compile in strict-iterator modeThiago Macieira2014-02-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unit-test this by making the QList, QVector, QHash and QMap unit tests be duplicated under strict-iterator mode. There's no test for QLinkedList. The tst_Collections test does not compile under strict-iterator mode. It generated over 15000 errors when I tried. The strict iterators required a small change: the difference_type typedef needs to match the operators that get distances (operator-(iterator)) and move the iterator around (+, -, +=, -=, etc.). Task-number: QTBUG-29608 Change-Id: I834873934c51d0f139a994cd395818da4ec997e2 Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com> Reviewed-by: Jason McDonald <macadder1@gmail.com>
* | Mark the QArrayData alloc/dealloc functions as nothrowThiago Macieira2014-02-191-2/+2
|/ | | | | | | Throwing is handled at a higher level. Change-Id: I573e4ded135b61e35fbe6e188be09acf449911fc Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
* Work around a binary incompatibility in MSVCThiago Macieira2014-01-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The fix in b8fe5e1bbc7f341d03d2704a6110d6e3240589bb (for bug QTBUG-27277) created two sets of begin() and end() functions for QVector. That was required because QTypedArrayData::iterator and QTypedArrayData::const_iterator have non-implicit copy constructors, which means the variants returning a strict iterator need to pass the storage pointer as an implicit first parameter. With the fix, the compiler would emit functions with two different names for each variant, which couldn't be merged. If we remove those copy constructors, the compiler might be able to generate the same code (no implicit first parameter) for both functions. Now, enter MSVC. Due to QPolygon, QVector<QPoint> and QVector<QPointF> are "extern templates". That is, the compiler is not allowed to inline anything, it must generate calls into QtCore (which we must fix for Qt 6, if we can). That means QtCore would only have one set of begin() / end() functions. If an application tried to use the other set by defining QT_STRICT_ITERATORS, you'd get a linker error for: ?begin@?$QVector@VQPoint@@@@QEAA?AViterator@?$QTypedArrayData@VQPoint@@@@V23@@Z (class QTypedArrayData<class QPoint>::iterator QGenericArray<class QPoint>::begin(class QTypedArrayData<class QPoint>::iterator)) Change-Id: I5c10a7d0a4855f4ba84056d313c6a800ecdcfe37 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com> Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* Remove QT_{BEGIN,END}_HEADER macro usageSergio Ahumada2013-01-291-4/+0
| | | | | | | | | | | The macro was made empty in ba3dc5f3b56d1fab6fe37fe7ae08096d7dc68bcb 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>
* Update copyright year in Digia's license headersSergio Ahumada2013-01-181-1/+1
| | | | | Change-Id: Ic804938fc352291d011800d21e549c10acac66fb Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Make sure functions returning iterators have an iterator as parameterThiago Macieira2012-10-191-6/+6
| | | | | | | | | | | | | | | | | | | | | The IA-64 C++ ABI does not encode the return type for non-template functions (QVector is the template, not the function), which means that these two functions have the same signature: Node *QVector<Node>::begin() typename class QTypedArrayData<Node>::iterator QVector<Node>::begin() [both are _ZN7QVectorI4NodeE5beginEv] When linking compilation units compiled with different QT_STRICT_ITERATORS settings, only one of the two out-of-line copies will survive. Depending on the ABI, we may have a problem: the ABI can say that a function returning a structure takes an implicit first parameter, which a function returning a regular pointer doesn't. Task-number: QTBUG-27277 Change-Id: I57a59e5a7c46f55faabfe85c073dca89d2a7bbf3 Reviewed-by: Jan Kundrát <jkt@flaska.net> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Change copyrights from Nokia to DigiaIikka Eklund2012-09-221-24/+24
| | | | | | | | 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: Fix gcc warning about parentheses in 'a + b & c'.Friedemann Kleint2012-07-061-1/+1
| | | | | Change-Id: I2c08dc8170c77de401663b1643ebca8484dbfec0 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
* Don't use the gcc extension for QStringLiteral & Q_ARRAY_LITERALLars Knoll2012-06-121-8/+0
| | | | | | | | | | | The extension doesn't work outside of function scopes, so a function declaration such as void foo(const QString &str = QStringLiteral("bar")); would fail on certain gcc versions. Change-Id: I2971301f2859edd3fc81b95dfa5a7c15f29e395c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* Fix the QVector build with C++11 initialiser listsThiago Macieira2012-06-011-2/+2
| | | | | | | | | | | | Initialiser lists were not tested before in the QVector rewrite, so the older malloc call was left behind. Also, std::initializer_list has const iterators returning const data and broke the build in a few places where const qualifiers were missing. Change-Id: I3c04e58361989aa7438621cda63c7df457d7dad8 Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@nokia.com>
* Make QVector compile with QT_STRICT_ITERATORS againThiago Macieira2012-06-011-6/+79
| | | | | | | | | | | | Move the iterator classes into QArrayTypedData and add constBegin() and constEnd() to that class. I also had to add an operator T*() to the strict iterators, since there are many places that expect the iterator to behave like a pointer (including in QVector itself). Change-Id: Icc5ed56ad47b013664a48eef9d31b5273aecb4e3 Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@nokia.com>
* Implement QVector with QArrayData interface.Jędrzej Nowacki2012-05-301-0/+12
| | | | | Change-Id: I109f46892aed2f6024459812d24922b12358814d Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Reuse QArray initializer macro in QByteArrayJędrzej Nowacki2012-05-041-4/+7
| | | | | Change-Id: Ieb12ee290846dce88f2ea9fbf943103899337e0f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix MSVC conversion warnings in new bytearray code.Friedemann Kleint2012-04-201-1/+1
| | | | | | Change-Id: Ifc81564daf3fef0d7f08ae8d250ba41d3b1d5b0f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
* Introduce QArrayData::detachCapacityJoão Abecasis2012-04-021-0/+7
| | | | | | | | | | | | | | | 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>
* Make QArrayData::shared_null zero terminated.Jędrzej Nowacki2012-03-291-3/+3
| | | | | | | This is expected by QByteArray and QString Change-Id: Ib668b144bdc0d2c793018c8f8d794f249eaf935c Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
* Ensure QTypedArrayData is just a shim over QArrayDataJoão Abecasis2012-03-281-0/+4
| | | | | Change-Id: I6f41ca054d0e0a0c4642f0b841b3b3df9559f818 Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
* Add AllocationOption::GrowJoão Abecasis2012-02-291-3/+4
| | | | | | | | | | | | | | | | | | | | | | | 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>
* Remove use of QT_MODULE from QArrayData stackJoão Abecasis2012-02-061-2/+0
| | | | | | | | The macro was made empty in 4ecf82795de54fba530ac9c386f3afff2174edbd, and is no longer necessary or used. Change-Id: If000ff51729e41bdcd1b0409961cf94d50e5f172 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Update license headersJoão Abecasis2012-02-061-3/+3
| | | | | | | | | | | - 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>
* Introducing Q_ARRAY_LITERALJoão Abecasis2012-01-251-0/+79
| | | | | | | | | | | | | | | | | | | 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>
* Enable use of QArrayDataPointer as a return typeJoão Abecasis2012-01-251-0/+7
| | | | | | | | | | | | | | | 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>
* Rename QArrayData::AllocateOption to AllocationOptionJoão Abecasis2012-01-161-10/+11
| | | | | Change-Id: Id3e7c748b4b40d703ad1785c903c96bdd968390e Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
* Enable QArrayData to reference external array dataJoão Abecasis2012-01-161-0/+23
| | | | | | | | | | | | | | | | | | | | | | 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>
* Add AllocateOptions to QArrayDataJoão Abecasis2012-01-091-4/+33
| | | | | | | | | | 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-14/+0
| | | | | | | | | | | | | | 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-4/+11
| | | | | | | | | | | | | | | 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>
* Retire the generic Q_REFCOUNT_INITIALIZER macroJoão Abecasis2012-01-041-1/+1
| | | | | | | | | | | | | 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>
* template<class T> struct QTypedArrayDataJoão Abecasis2011-12-111-0/+42
| | | | | | | | | | 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/+5
| | | | | | | | | | | | | | | | | | | 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>
* Introducing QArrayDataJoão Abecasis2011-12-061-0/+97
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-04-27 04:41:50 +0000