| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
The const qualification prevented toUpper() etc from
calling the rvalue overloads of the corresponding QString
functions. Since resolved() always returns a non-shared
object, the rvalue overloads can re-use the object's
capacity for storing their result, saving up to one memory
allocation per QStringBuilderCommon::to*() invocation.
Change-Id: Ica97fcd906cdd949ffe56055654578b93407e2d3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old code did the equivalent of strcpy(), thus stopping
at the first NUL byte, ignoring the QLatin1String's size().
That is not acceptable, for two reasons:
1. Appending QLatin1String to a QString uses the size(), too.
2. The QConcatenable claims an ExactSize = true, so
it cannot go and write less data than it's own
size() said it would. Even worse, it will happily
write _more_ data, too, if the QLatin1String is
not properly zero-terminated.
This change has low risk, because the equivalent change
to the QString branch has been applied between 5.2 and
5.3 (in fd0f1bc3), with no complaints from the user base.
It is also in a branch that is very unlikely to be taken:
Since QConcatenable<QLatin1String> is setting ConvertTo
to QString, any QStringBuilder expression containing it
will only implicitly convert to QString, not QByteArray.
In fact, I don't even know how to make it invoke the
changed code in normal operation...
Change-Id: I486a76352af7f318ba05da845d3afee7d826c92a
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
| |
warning: implicit conversion loses integer precision: 'long' to 'int' [-Wshorten-64-to-32]
a.resize(it - a.constData());
~ ~~~^~~~~~~~~~~~~~~
Change-Id: I8c199d69f2e0d41d1c288d452b9d621b201fa98e
Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
- Renamed LICENSE.LGPL to LICENSE.LGPLv21
- Added LICENSE.LGPLv3
- Removed LICENSE.GPL
Change-Id: Iec3406e3eb3f133be549092015cefe33d259a3f2
Reviewed-by: Iikka Eklund <iikka.eklund@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
Task-number: QTBUG-7233
Change-Id: I52067e3a22e98a62fd87415906e54a54ff2d6b49
Reviewed-by: Kurt Pattyn <pattyn.kurt@gmail.com>
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Dave McClelland
|
|
|
|
|
|
|
|
|
| |
Disassembly shows that the compiler does not perform the zero-expansion
by itself. It always opts to copy byte-by-byte, which is not very
performant.
Change-Id: I08780902461d9e3e6b7b54298f41d1eca61339c4
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without this const_cast, the call to QString::data() or
QByteArray::data() will cause a call to detach(), which is totally
unnecessary since we've just allocated data a couple of lines before.
Since we know we're the owner of the only reference, we can skip the
detach attempt.
Change-Id: If40f66100f85cc9b405025f21c562828ead23475
Reviewed-by: hjk <hjk121@nokiamail.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
Change-Id: Ic804938fc352291d011800d21e549c10acac66fb
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Any file including qstringbuilder.h would trigger a warning when
compiled with QT_ASCII_CAST_WARNINGS defined since it implicitely
converts a QString to QByteArray.
Explicitely call toUtf8() to fix the issue.
Change-Id: If20f9d4571c5d1ed789564196c9f1331e1efd1d9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
Previously, the append functions in QConcatenable in the QStringBuilder
dereferenced the data() pointer of the argument QLatin1String without
performing null check.
Change-Id: I629f19fbce3113f1f80f4272fa7ae34e1dbc6bee
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
|
|
|
|
|
|
|
| |
in order of consistency with QChar
Change-Id: I8a7cf8960eb64ef177113d4569f1c49ae31c828e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
| |
Task-Id: QTBUG-24502
Change-Id: I360dee4dc68c165de0631ce4cf34e76fd873080e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
| |
Just to match the ones that are already there.
Change-Id: I25acc2391feded4cac79ebf65a6bc72176f5f931
Reviewed-by: hjk <qthjk@ovi.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit completes the previous commit so that both QString and
QStringBuilder now operate on UTF-8 input.
A small fix was required in QStringBuilder: an if clause isn't enough
to separate the two append versions. Since there are no QString
functions that append to char*, if we're converting to a QByteArray,
we need to go through a QString first in a separate function.
Change-Id: Ic503340c5d0c32d420c90c91cc2e0fc1ae9230f3
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Up until now, the macros would return an internal type that contained
the pointer to the data. This breaks code that tried to use the macros
with operators, like QStringBuilder but also when writing:
QStringList() << QStringLiteral("a") << QStringLiteral("b");
This change seems to work fine now and I can also verify that this
works:
const auto str = QStringLiteral("Hello");
Even though it creates a QString, which is non-POD and non-constexpr.
Change-Id: Iaf82af9bea4245513a1128ea54f9d2d3d785fb09
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were two constuctors offering essentially the same functionality.
One taking the QStatic*Data<N> struct, the other what essentially
amounts to a pointer wrapper of that struct. The former was dropped and
the latter untemplatized and kept, as that is the most generic and
widely applicable. The template parameter in the wrapper was not very
useful as it essentially duplicated information that already maintained
in the struct, and there were no consistency checks to ensure they were
in sync.
In this case, using a wrapper is preferred over the use of naked
pointers both as a way to make explicit the transfer of ownership as
well as to avoid unintended conversions. By using the reference count
(even if only by calling deref() in the destructor), QByteArray and
QString must own their Data pointers.
Const qualification was dropped from the member variable in these
wrappers as it causes some compilers to emit warnings on the lack of
constructors, and because it isn't needed there.
To otherwise reduce noise, QStatic*Data<N> gained a member function to
directly access the const_cast'ed naked pointer. This plays nicely with
the above constructor. Its use also allows us to do further changes in
the QStatic*Data structs with fewer changes in remaining code. The
function has an assert on isStatic(), to ensure it is not inadvertently
used with data that requires ref-count operations.
With this change, the need for the private constructor taking a naked
Q*Data pointer is obviated and that was dropped too.
In updating QStringBuilder's QConcatenable specializations I noticed
they were broken (using data, instead of data()), so a test was added to
avoid this happening again in the future.
An unnecessary ref-count increment in QByteArray::clear was also
dropped.
Change-Id: I9b92fbaae726ab9807837e83d0d19812bf7db5ab
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
| |
This should fix the declarative build.
Change-Id: I32dd5b7783995759f27d016c801ae6dfb3d44733
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
|
|
|
|
|
|
|
|
| |
This will allow separation of API that should work with QString
results, and API that should work with QByteArray results.
Change-Id: I5be398188abd421bb5056cea2658ea85fc03aa4f
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/kernel/qmetaobject.cpp
src/corelib/kernel/qvariant.cpp
src/tools/moc/moc.h
Change-Id: I2cd3d95b41d2636738c6b98064864941e3b0b4e6
|
| |
| |
| |
| |
| | |
Change-Id: I3c91fd516bb13e5534aa6f26ee9df745c990dfb5
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
|
| |
| |
| |
| |
| | |
Change-Id: I162da3e373a0191f69e50e110114ef78c2d5fc66
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
|
|\|
| |
| |
| | |
Change-Id: I97ba222435ff50a9e5422e6f2c73e4bb8d1b865c
|
| |
| |
| |
| |
| |
| |
| |
| | |
This isn't used, and isn't wanted with the upcoming utf8 switch.
Change-Id: Ibec0fa7f36549df6a1c240353ffcd44beb2976f0
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This setting is extremely harmful, as code cannot know whether or not to expect
it. It also made the behaviour of QString::fromAscii and ::toAscii unintuitive,
and caused a lot of people to make mistakes with it.
Change-Id: I2f429fa7ef93bd75bb93a7f64c56db15b7283388
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There is no need to do a bytewise copy looking for the terminating
nul-character when the size of the data is statically declared and known
ahead of time.
Change-Id: I787745a58955d1a366624f9ea92e9e701de8c981
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/tools/qstring.cpp
Change-Id: I23d214bf33c2badfae1876da3cc7d6d8f6e635fb
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As in the past, to avoid rewriting various autotests that contain
line-number information, an extra blank line has been inserted at the
end of the license text to ensure that this commit does not change the
total number of lines in the license header.
Change-Id: I311e001373776812699d6efc045b5f742890c689
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These defines were there to aid in the commercial
licensing scheme we used long ago, and are no longer needed.
Keep a QT_MODULE(x) define so other modules continue compiling.
Change-Id: I8fd76cd5270df8f14aee746b6cf32ebf7c23fec7
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
|
| |
| |
| |
| |
| |
| |
| | |
Replace Nokia contact email address with Qt Project website.
Change-Id: I431bbbf76d7c27d8b502f87947675c116994c415
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
|
|\|
| |
| |
| | |
Change-Id: I2d358b912f1055ee6021d13de2f66fd459aaa355
|
| |
| |
| |
| |
| | |
Change-Id: I02f2c620296fcd91d4967d58767ea33fc4e1e7dc
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before, it was the length + 1, to include the ending \0 (for historical
reasons)
Having it the actual length is more intuitive and less error prone
Also added QT_ASCII_CAST_WARN to QConcatenable<QByteArray>::appendTo
to show the warnig that convertion from ascii to qstring occurs.
Change-Id: Ie7c8552b6b4e7ccb393cb09f5f0ca9b00336c714
Reviewed-by: thiago
Reviewed-on: http://codereview.qt.nokia.com/1988
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Olivier Goffart <olivier.goffart@nokia.com>
|
|
|
|
|
|
|
|
|
|
| |
This requires a fix for QByteArrayLiteral to work too.
Change-Id: I3c2a50ad431d5b0c014a341e675fa54e7b206e70
Merge-request: 27
Reviewed-by: Olivier Goffart <olivier.goffart@nokia.com>
Reviewed-on: http://codereview.qt.nokia.com/1967
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise we get errors for failing to have operator+ properly when
writing:
QStringLiteral("foo") + s
Change-Id: I03844c95e9fdfa886eadfa2b5fe104ff048fd618
Reviewed-on: http://codereview.qt.nokia.com/1351
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unify the two classes and get rid of one
TODO item for Qt 5.
Using strlen in the constructor of QLatin1String works,
as the compiler can do the calculation at compile time.
Change-Id: I59d98c71a34b86d4211fa0d8cfd40b7d612c5a78
Reviewed-on: http://codereview.qt.nokia.com/1219
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Olivier Goffart <olivier.goffart@nokia.com>
|
|
|
|
|
|
|
|
|
| |
This is supported by the others operator+
Change-Id: I9a1d1a0afb63acf32935948111d43ca6da370363
Reviewed-on: http://codereview.qt.nokia.com/764
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: hjk <qthjk@ovi.com>
|
|
|
|
|
|
|
| |
Updated version of LGPL and FDL licenseheaders.
Apply release phase licenseheaders for all source files.
Reviewed-by: Trust Me
|
|
|
|
|
|
|
|
|
|
|
|
| |
In 4.8 we added support for using StringBuilder with QByteArray.
But this is breaking source compatibility for people that used
QT_USE_FAST_OPERATOR_PLUS in Qt 4.7. So we introduce a new macro
Notice that QT_USE_FAST_CONCATENATION was not working without
QT_USE_FAST_OPERATOR_PLUS, so we remove the checking of that macro.
Reviewed-by: joao
(cherry picked from commit 8447f5616be731d78081f326bb9cb3f5aa9087a4)
|
|
This is the beginning of revision history for this module. If you
want to look at revision history older than this, please refer to the
Qt Git wiki for how to use Git history grafting. At the time of
writing, this wiki is located here:
http://qt.gitorious.org/qt/pages/GitIntroductionWithQt
If you have already performed the grafting and you don't see any
history beyond this commit, try running "git log" with the "--follow"
argument.
Branched from the monolithic repo, Qt master branch, at commit
896db169ea224deb96c59ce8af800d019de63f12
|