| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|\
| |
| |
| | |
Change-Id: I2d358b912f1055ee6021d13de2f66fd459aaa355
|
| |
| |
| |
| |
| |
| | |
Change-Id: Ib8725e89e40d6e12172b1da687da2e4d559444f3
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
|
| |
| |
| |
| |
| |
| | |
Change-Id: Id9635b6faeaf12ba2f7a0f70055b0df01cd16587
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
|
| |
| |
| |
| |
| |
| | |
Change-Id: I302be7dc4cd7a9c2b9e35e8142ca100d6f86da7c
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
|
| |
| |
| |
| |
| |
| | |
Change-Id: I4bbe18ecc342f034fbc8e9fd14b700ee5272076f
Reviewed-by: Denis Dzyubenko <denis.dzyubenko@nokia.com>
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
|
| |
| |
| |
| |
| |
| |
| | |
Task-number: QTBUG-22500
Change-Id: If530799cf8ef971f5caf78d0c6dbeeda719d148f
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
The previous change missed some headers from years prior to 2011, and a
few new files were merged after the previous change.
Change-Id: Ib7d1a2b7062228c2a5373da64242b2ee1f0981e1
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QDebug stream operator was added for:
QPixmap, QImage, QUuid, QBitArray, QLocale, QRegExp, QCursor,
QPalette, QTextFormat, QTextLength, QIcon and QSizePolicy
Change-Id: Ibcf5c9b599ba322d53cb106d8e5e157427ebe757
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Reviewed-by: Denis Dzyubenko <denis.dzyubenko@nokia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Four overload functions removed while keeping source compatibility:
- shortMonthName()
- shortDayName()
- longMonthName()
- longDayName()
Two functions removed since they have confusing names:
- gregorianToJulian()
- julianToGregorian()
Change-Id: Iaaea066a3fb77b1ee3499d3049fcec5563054cdf
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: John Layt <jlayt@kde.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It is mostly not used (most places in Qt use typename directly), so
is already not very useful.
For example typename is used in:
QDataStream& operator<<(QDataStream& s, const QVector<T>& v)
Change-Id: I85337ad7d8d4ebbb424bfa2ab9a356456ff3e90f
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Deprecated QGuiApplication::keyboardInputLocale() and
keyboardInputDirection(), introduced QInputPanel::locale()
and inputDirection().
Change-Id: Ic48c77f10821a949751c73c73f22bd78e2192b9c
Reviewed-by: Joona Petrell <joona.t.petrell@nokia.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We're trying to deprecate these, so don't use them anymore.
The inline uses of these have been left intact, for the moment. Inline code will
need to create their own non-inline allocation methods (for future-proofing to
allow alterations in how e.g. individual containers allocate)
Change-Id: I1071a487c25e95b7bb81a3327b20c5481fb5ed22
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
|
| |
| |
| |
| |
| | |
Change-Id: I02f2c620296fcd91d4967d58767ea33fc4e1e7dc
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some time ago this was a blocker that didn't allow to refactor QLocale
implementation due without making binary incompatible changes. Deinlining those
functions for Qt5, it shouldn't be performance critical code path.
Change-Id: I6cb19e32188a2df223d04be0c613a6176ad8d118
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Pure syntactical sugar, to match up with what the other container
classes offer.
Change-Id: I0f97de011923d9d204cca0fa906b059dc5054a89
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This adds a new function (and tests) to give the possibility of doing a
QCryptographicHash of a QIODevice, like a QFile or whatever people
needs.
It is a quite handy overload in many cases.
Change-Id: I22fd272f05571844641b3daefcc6746be4e5c7c3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| | |
We don't support gcc 2.95 any more.
Change-Id: I842f1f8ac64b9006516c104add0991830ac9a46a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| | |
This allows us to benefit from compile-time optimization
Change-Id: I63dfde3758fcb0ff919fdc0418df1b7586da0b2f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
This allows us to benefit from compile time optimizations when calling
strlen()
Change-Id: If6694117e613a012fce97f8664e6b43005d255de
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This also adds a unit test for length()/count()/size(), since there wasn't one
testing it explicitly.
Change-Id: Ifb7f113aa97beef5f76e5fb246eb38495344b0ad
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
Reviewed-by: Marco Schmidt <Marco.Schmidt@Taugamma.de>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
|
| |
| |
| |
| |
| |
| |
| | |
Note: This constitutes a break in Binary Compatibility.
Change-Id: I050587901725b701f20dd46475ae48aec28aa54d
Reviewed-by: Bradley T. Hughes <bradley.hughes@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>
|
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
, and make it strictly a POD struct.
Since this operator was only being used to set the initial (owned) value
of the reference count, the name of the function introduced here to
replace it makes that use case explicit.
Change-Id: I2feadd2ac35dcb75ca211471baf5044a5f57cd62
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
|\|
| |
| |
| | |
Change-Id: I01f94564c17d68872839be5396c24b661e53d571
|
| |
| |
| |
| |
| |
| |
| | |
Change-Id: I79010e1ecfdfe579d996db65681ab1559598f3ce
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
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>
|
|
|
|
|
|
|
|
| |
Warning C4308: negative integral constant converted
to unsigned type.
Change-Id: Ibdb14ad2ceebd56715fda861151e92f6dc10f955
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
| |
Merge-request: 1456
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
(cherry picked from commit e0383c9b8bd6f4e3d445d69690f84209cad42bb5)
Change-Id: Ie0383c9b8bd6f4e3d445d69690f84209cad42bb5
|
|
|
|
|
| |
Change-Id: Ida722f013613d8633867a902660da30d28aeb918
Reviewed-by: Aaron Kennedy <aaron.kennedy@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
gcc 4.6 becomes the minimum required version in Qt 5.
See also d4150975af620e2889cc58bd476bac6b4d101db3
in Qt 4.8.
Change-Id: If66ce0be755263c20b0a4371523c6590592d962d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
|
|
|
|
|
|
|
|
|
| |
This tests that the moc generated file produces no warnings with very
pedentic compilation flags.
In that case, there was a warning because of the use of the C casts
Change-Id: Ie79c6d053ff35c55276a07212c5d60f759f693ee
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For -O2 gcc activates -fstrict-aliasing. As a result the compiler is
allowed to assume that pt[1]=px[1]/3+B1 does not affect t.
Therefore the result of _fast_cbrt() was always 0.
Using a union for casting avoids this issue.
For more details see:
http://labs.qt.nokia.com/2011/06/10/type-punning-and-strict-aliasing
Also the updated code respect endianness.
Change-Id: Id4bed16efac52e494e7357dc2f23f94e8c525df1
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 9358f7eaa4b773bdbfa45b08ab92a89096954881.
The change is source incompatible and hasn't been agreed upon. Revert
it even though it's correct in principle. It's simple to keep the old
enums around for compatibility.
Change-Id: I8d9d33868e44d0299a3f081833b06cedf0ed4345
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
| |
Singhalese -> Sinhalese
Divehi -> Dhivehi
Change-Id: I3faa7163202a4a9be14e3cf857da60aa4dd3196f
Reviewed-by: Jiang Jiang <jiang.jiang@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I added the possibilty to define Bezier/TCB splines and use them
as custom easing curves.
Note:
Splines have a parametric definition. This means we have a
function/polynom of t that evalutes to x and y. x/y = f(t).
For our purpose we actually need the function y = f(x).
So as a first step we have to solve the solution x = f(t) for a given
t and then in a second step we evaluate y = f(t).
f(t) is a cubic polynom so we use cardanos formula to solve this equation
directly.
For the casus irreducibilis we need 3 functions that are a combination of
arcos and cos. Instead of evaluating arcos and cos we approximate these
functions directly.
TCB splines are converted into the corresponding cubic bezier spline.
Change-Id: Id2afc15efac92e494d6358dc2e11f94e8c524da1
Reviewed-by: Aaron Kennedy <aaron.kennedy@nokia.com>
|
|
|
|
|
| |
Change-Id: Ia7ef1a8e01001f203e409c710c977d6f4686342e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
| |
* QDataStream format documented
* Added Unit test for QDataStream operators
* Updated Unit test
Change-Id: Idbcfcb0b927e6369e8d31b57693c7aa0d1a154e7
Reviewed-by: Olivier Goffart <ogoffart@kde.org>
|
|
|
|
|
|
|
|
| |
Merge-request: 69
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Change-Id: I61f5a54b783252029fcad95677958fa6a2130d01
Reviewed-by: Olivier Goffart <ogoffart@kde.org>
|