On Tuesday 21 July 2015 12:40:26 Marc Mutz wrote:
So start using qMove() or pass temporaries in your QVector::append()
calls.
Are we also using move internally when resizing and detaching?
No.
For detach, we cannot (we need a copy).
For resize, the pressure to implement it
Thiago Macieira thiago.macie...@intel.com
Or like QString and QByteArray will be in Qt 6.
Are these still implicitly shared?
Yes, in large mode. In small string/array mode, they wouldn't share, of
course.
What about the conversion of std::vector to QVector and back. Do we get zero
copy
On Tuesday 21 July 2015 10:38:46 Peter Kuemmel wrote:
Is it obvious that the Qt 5.4.1 version installed by the system on a KDE
machine is binary incompatible to a locally compiled Qt 5.5.0?
It shouldn't be. Qt versions are supposed to be binary compatible with each
other from the point of view
On Tuesday 21 July 2015 16:00:45 Takao Fujiwara wrote:
We don't develop gtk. We do develop Qt4 and we know that supporting
complex
input methods with it was a pain and it often regressed due to lack of
testing. I think limiting the testing is doing a disservice to our users.
However I
On Tuesday 21 July 2015 08:55:42 Thiago Macieira wrote:
In my version of QVector, this is already implemented. Movable and trivial
types are simply realloc()ed, so no copy takes place.
Oops, no, sorry, this only works for types that also don't require special
alignment (less than
Hi,
https://codereview.qt-project.org/#/c/120804/ and
https://codereview.qt-project.org/#/c/120771 do fix the move assignment
operators in Qt, just like I wanted.
I wonder why Marc Mutz didn't fell the need to update the mailing list on his
changed opinion and this fix.
Anyway, for those
On Tuesday 21 July 2015 06:47:16 Hausmann Simon wrote:
Hi,
This is true. xmlpatterns is still on the Jenkins based CI. It's one of the
few modules we haven't moved over yet, due to the way it tests (well, the
truth is that it doesn't actually run any blocking tests, for years :)
I see two
On 2015-07-21 11:53, Thiago Macieira wrote:
On Tuesday 21 July 2015 09:09:36 Julien Blanc wrote:
On 2015-07-20 15:26, Thiago Macieira wrote:
But assuming I am pushing
back a T, is there any reason I'd want emplace_back? Or vice-versa?
emplace_back is really designed to avoid the creation of
On Tuesday 21 July 2015 14:43:49 Marc Mutz wrote:
On Tuesday 21 July 2015 13:27:51 Giuseppe D'Angelo wrote:
Hi,
I'd like to nominate Sérgio Martins for the Approver status in the Qt
project.
Oh, he's not an approver, yet? And here I was wondering why I only ever got
+1 from him :)
On Tuesday 21 July 2015 10:19:59 Matthew Woehlke wrote:
On 2015-07-21 01:06, Thiago Macieira wrote:
On Tuesday 21 July 2015 02:26:41 Kevin Kofler wrote:
For the implicitly shared data types, QList actually does NOT add another
layer of indirection (as documented: If T is itself a pointer
On Tuesday 21 July 2015 11:56:58 BogDan wrote:
Hey,
It's juts me or CI is broken again? I'm trying to push a two patches[0] for
a few days with no luck ...
s/again/still/
It's the same QTemporaryDir issue on Windows.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect
On Tuesday 21 July 2015 09:09:36 Julien Blanc wrote:
The templateness changes how a type different than the vector's type gets
constructed (it might undergo a conversion first).
Not sure i understand you well there. The variadic and templateness
changes it so that no temporary gets
On 07/22/15 00:49, Thiago Macieira-san wrote:
On Tuesday 21 July 2015 16:00:45 Takao Fujiwara wrote:
We don't develop gtk. We do develop Qt4 and we know that supporting
complex
input methods with it was a pain and it often regressed due to lack of
testing. I think limiting the testing is
On Tuesday 21 July 2015 14:43:49 Marc Mutz wrote:
I'd like to nominate Sérgio Martins for the Approver status in the Qt
project.
Oh, he's not an approver, yet? And here I was wondering why I only ever got
+1 from him
+1
Same here. +1 from me.
(Disclaimer: he's a colleague of mine
On Tuesday 21 July 2015 17:53:55 Thiago Macieira wrote:
I'm asking why one of the two would be better than the other if I'm trying
to add a single T to std::vectorT. You've explained that emplace_back
is efficient, but you haven't said whether push_back is as efficient, more
efficient or less
Am 21.07.2015 um 19:14 schrieb Matthew Woehlke mwoehlke.fl...@gmail.com:
Ergo, that implementation looks... suspicious, and *may* even be
non-conforming. (Unless push_back is doing something really funky, which
I somewhat doubt.) You may want to file a bug against that implementation.
this
On Tuesday 21 July 2015 19:11:42 Bubke Marco wrote:
Thiago Macieira thiago.macie...@intel.com
On Tuesday 21 July 2015 16:14:18 Bubke Marco wrote:
Thiago Macieira thiago.macie...@intel.com
Or like QString and QByteArray will be in Qt 6.
Are these still implicitly
On Tuesday 21 July 2015 16:14:18 Bubke Marco wrote:
Thiago Macieira thiago.macie...@intel.com
Or like QString and QByteArray will be in Qt 6.
Are these still implicitly shared?
Yes, in large mode. In small string/array mode, they wouldn't share, of
course.
What about the
On Tuesday 21 July 2015 12:22:36 Matthew Woehlke wrote:
std::vectorQPen list;
// less efficient
auto pen = QPen{Qt::red, 1.5f};
list.push_back(pen);
// more efficient
list.emplace_back(Qt::blue, 2.0f);
This is a lot clearer. Thanks!
--
Thiago Macieira - thiago.macieira
We would like to announce our release of CopperSpice 1.1.0. We have
added and changed several things including a modification to to QMap to
user defined comparisons. We have a timeline others may be interested in
viewing in our overview documentation. We will have API documentation
uploaded
void push_back(T t) {
ensureCapacity(size() + 1);
new (m_end) T(std::move(t));// move-construct from t
++m_end;
why is std::move needed here? Afaik std::move(t) converts t into a rvalue ref,
but t is already an r-value ref.
Regards,
Gunnar
Hi Ansel.
Am 21.07.2015 um 19:06 schrieb Ansel Sermersheim an...@copperspice.com:
gives the Qt Project the freedom to take any and all submissions and
incorporate them into the closed source version
Do not mix up commercial license with closed source, all code you contribute
will be
On Tue, Jul 21, 2015 at 12:49 PM Gunnar Roth gunnar.r...@gmx.de wrote:
void push_back(T t) {
ensureCapacity(size() + 1);
new (m_end) T(std::move(t));// move-construct
from t
++m_end;
why is std::move needed here? Afaik std::move(t)
On Tuesday 21 July 2015 19:49:13 Gunnar Roth wrote:
void push_back(T t) {
ensureCapacity(size() + 1);
new (m_end) T(std::move(t));// move-construct
from t
++m_end;
why is std::move needed here? Afaik std::move(t)
Thiago Macieira thiago.macie...@intel.com
On Tuesday 21 July 2015 16:14:18 Bubke Marco wrote:
Thiago Macieira thiago.macie...@intel.com
Or like QString and QByteArray will be in Qt 6.
Are these still implicitly shared?
Yes, in large mode. In small string/array mode, they
Gunnar Roth gunnar.r...@gmx.de
void push_back(T t) {
ensureCapacity(size() + 1);
new (m_end) T(std::move(t));// move-construct from
t
++m_end;
why is std::move needed here? Afaik std::move(t) converts t into a rvalue
ref, but t is
Hello,
Out of curiosity i just looked at the Xcode 6.4 headers for the implementation
of std::vector::emplace_back,
and i don’t think there is any difference between push_back(QPen(Qt::red,1.5f))
and emplace_back(Qt::red,1,5f))
The implementation is like this:
template class... _Args
Since this touches on a possible standards issue, CC'ing the standards list.
On 2015-07-21 13:00, Gunnar Roth wrote:
Hello,
Out of curiosity i just looked at the Xcode 6.4 headers for the
implementation of std::vector::emplace_back,
and i don’t think there is any difference between
On Tuesday 21 July 2015 18:32:09 Ansel Sermersheim wrote:
On 7/21/15 6:23 PM, Thiago Macieira wrote:
Right, we usually work around this by having QMapCaseInsensitiveString,
X.
Certainly possible to do, but sometimes quite awkward depending on the
situation.
Agreed.
I don't see the need
On Wednesday 22 July 2015 12:41:11 Takao Fujiwara wrote:
On 07/22/15 00:49, Thiago Macieira-san wrote:
On Tuesday 21 July 2015 16:00:45 Takao Fujiwara wrote:
We don't develop gtk. We do develop Qt4 and we know that supporting
complex
input methods with it was a pain and it often regressed
On Tuesday 21 July 2015 18:10:27 Ansel Sermersheim wrote:
The most common use case of this is creating a QMapQString, X that is
sorted case insensitively. The STL allows this for std::map, and coming
to Qt from a background of standard C++ I was amazed that this very
common use case was not
On 7/21/15 3:15 PM, Marc Mutz wrote:
On Tuesday 21 July 2015 22:26:17 Ansel Sermersheim wrote:
As to your question about relicensing, can you please elaborate on what
this is referring to? As long as Qt is covered by the current license,
we can not relicense CopperSpice since we are bound by
On 7/21/15 6:23 PM, Thiago Macieira wrote:
On Tuesday 21 July 2015 18:10:27 Ansel Sermersheim wrote:
The most common use case of this is creating a QMapQString, X that is
sorted case insensitively. The STL allows this for std::map, and coming
to Qt from a background of standard C++ I was
Am 21.07.2015 um 19:58 schrieb Milian Wolff milian.wo...@kdab.com:
On Tuesday 21 July 2015 19:49:13 Gunnar Roth wrote:
void push_back(T t) {
ensureCapacity(size() + 1);
new (m_end) T(std::move(t));// move-construct
from t
++m_end;
On Tuesday 21 July 2015 18:11:20 Daniel Teske wrote:
I wonder why Marc Mutz didn't fell the need to update the mailing list on
his changed opinion and this fix.
Read the whole mail you're replying to, and the follow-ups:
On Monday 29 June 2015 17:50:31 Thiago Macieira wrote:
On Monday 29
On Tuesday 21 July 2015 19:53:14 Gunnar Roth wrote:
Hi Ansel.
Am 21.07.2015 um 19:06 schrieb Ansel Sermersheim an...@copperspice.com:
gives the Qt Project the freedom to take any and all submissions and
incorporate them into the closed source version
Do not mix up commercial license
On Tuesday 21 July 2015 17:11:42 Bubke Marco wrote:
Thiago Macieira thiago.macie...@intel.com
What about the conversion of std::vector to QVector and back. Do we get
zero copy conversion?
Can't be done.
What about wrapping QVector around std::vector.
Can't be done either if we want
Il 21/07/2015 20:37, Thiago Macieira ha scritto:
As opposed to qMapLessThanKey? Do you mean two QMap with the same key could
have different comparators?
Why not? Suppose you want to have maps sorting by different criteria,
especially if the type doesn't have proper semantics for operator and
On Tuesday 21 July 2015 10:06:52 Ansel Sermersheim wrote:
We would like to announce our release of CopperSpice 1.1.0. We have
added and changed several things including a modification to to QMap to
user defined comparisons.
As opposed to qMapLessThanKey? Do you mean two QMap with the same
Am 21.07.2015 um 20:11 schrieb Bubke Marco marco.bu...@theqtcompany.com:
Gunnar Roth gunnar.r...@gmx.de
void push_back(T t) {
ensureCapacity(size() + 1);
new (m_end) T(std::move(t));// move-construct from t
++m_end;
why is std::move needed
On Tuesday 21 July 2015 20:11:33 Bubke Marco wrote:
Gunnar Roth gunnar.r...@gmx.de
void push_back(T t) {
ensureCapacity(size() + 1);
new (m_end) T(std::move(t));// move-construct
from t ++m_end;
why is std::move needed
Hi Gunnar,
We used to say Qt which we thought was the name of the project. We
were asked to use the name The Qt Project. We do not mind changing
how we address the company and the library. Since we meant to harm may
we suggest this be conveyed to others a little more gently.
As to your
Hi Marc,
We do own copperspice.com, .org, .net, and .info. We set .com up as the
primary site for no particular reason.
There is no question that making money is of value. However, our main
goal at this time is to develop CopperSpice and share it with the
community. We believe money will
On Tuesday 21 July 2015 20:52:05 Giuseppe D'Angelo wrote:
Il 21/07/2015 20:37, Thiago Macieira ha scritto:
As opposed to qMapLessThanKey? Do you mean two QMap with the same key
could have different comparators?
Why not? Suppose you want to have maps sorting by different criteria,
On Tue, Jul 21, 2015 at 10:26 PM, Ansel Sermersheim an...@copperspice.com
wrote:
As to your question about relicensing, can you please elaborate on what
this is referring to? As long as Qt is covered by the current license,
we can not relicense CopperSpice since we are bound by the terms of the
On 7/21/15 11:37 AM, Thiago Macieira wrote:
On Tuesday 21 July 2015 10:06:52 Ansel Sermersheim wrote:
We would like to announce our release of CopperSpice 1.1.0. We have
added and changed several things including a modification to to QMap to
user defined comparisons.
As opposed to
On 7/21/15 4:03 PM, Thiago Macieira wrote:
On Tuesday 21 July 2015 20:52:05 Giuseppe D'Angelo wrote:
Il 21/07/2015 20:37, Thiago Macieira ha scritto:
As opposed to qMapLessThanKey? Do you mean two QMap with the same key
could
have different comparators?
Why not?
Not passing judgement. I was
On Tuesday 21 July 2015 20:52:05 Giuseppe D'Angelo wrote:
Il 21/07/2015 20:37, Thiago Macieira ha scritto:
As opposed to qMapLessThanKey? Do you mean two QMap with the same key
could
have different comparators?
Why not?
Not passing judgement. I was only asking for clarification, since
On Tuesday 21 July 2015 12:21:35 Ansel Sermersheim wrote:
Hi Gunnar,
We used to say Qt which we thought was the name of the project. We
were asked to use the name The Qt Project. We do not mind changing
how we address the company and the library. Since we meant to harm may
we suggest this
On Wednesday 22 July 2015 00:15:19 Marc Mutz wrote:
You own the copyright to those parts which you added. Come GPL4, you might
conceivably want to use that license. Assuming TQC releases its code under
GPL4, too, which it can, that leaves your own original work. Assuming it's
just you and
On Tuesday 21 July 2015 15:48:29 Thiago Macieira wrote:
[snip]
Oops, I added the wrong mailing list in reply. Please ignore this. Unless
you're interested in IoTivity, in which case you can continue to follow this
discussion in the iotivity-...@lists.iotivity.org mailing list.
(Soonhwang,
On Tuesday 21 July 2015 09:38:20 최순황 wrote:
Dear All
We are Samsung QA team for IoTivity.
We should execute our QA TC for IoTivity 0.9.2 Release.
but 70% of our CA TC use that API ( CAGetNetworkInformation() ) to get IP
and Port information.
if 'CAGetNetworkInformation()'
On Tuesday 21 July 2015 14:36:19 Takao Fujiwara wrote:
* We need at least one input context to use and test against (on Linux)
when developing Qt further. Not having the plugin in qtbase will lead to
us not testing IMEs on Linux anymore, something I really want to avoid.
I think you don't
On 07/21/15 15:07, Thiago Macieira-san wrote:
On Tuesday 21 July 2015 14:36:19 Takao Fujiwara wrote:
* We need at least one input context to use and test against (on Linux)
when developing Qt further. Not having the plugin in qtbase will lead to
us not testing IMEs on Linux anymore, something
From: development-bounces+marco.bubke=theqtcompany@qt-project.org
development-bounces+marco.bubke=theqtcompany@qt-project.org on behalf of
Kevin Kofler kevin.kof...@chello.at
If you have large objects, and insert or remove items within the list,
QVector will have to move (or even
Op 21-7-2015 om 11:55 schreef Bubke Marco:
From: development-bounces+marco.bubke=theqtcompany@qt-project.org
development-bounces+marco.bubke=theqtcompany@qt-project.org on behalf
of Kevin Kofler kevin.kof...@chello.at
If you have large objects, and insert or remove items within the
On 21/07/15 09:00, Takao Fujiwara tfuji...@redhat.com wrote:
On 07/21/15 15:07, Thiago Macieira-san wrote:
On Tuesday 21 July 2015 14:36:19 Takao Fujiwara wrote:
* We need at least one input context to use and test against (on
Linux)
when developing Qt further. Not having the plugin in qtbase
Le lundi 20 juillet 2015 à 12:26 -0700, Thiago Macieira a écrit :
On Monday 20 July 2015 18:25:43 Keith Gardner wrote:
What's the difference in std::vector between an rvalue push_back and
emplace_back?
emplace_back takes variadic template arguments to construct the item
directly in
+1
(Also a colleague at KDAB)
On Tue, Jul 21, 2015 at 01:27:51PM +0200, Giuseppe D'Angelo wrote:
Hi,
I'd like to nominate Sérgio Martins for the Approver status in the Qt
project.
In the last years Sérgio has pushed lots of patches in a number of
components: he worked on the QNX/BB
Looks like it's broken for qtwayland too.
https://codereview.qt-project.org/#/c/120705/
Though I don't get what ci-osx109-x64-09 has to do with qtwayland
which is Linux only.
2015-07-21 13:56 GMT+02:00 BogDan bog_dan...@yahoo.com:
Hey,
It's juts me or CI is broken again? I'm trying to push a
Hi,
I'd like to nominate Sérgio Martins for the Approver status in the Qt
project.
In the last years Sérgio has pushed lots of patches in a number of
components: he worked on the QNX/BB platform plugin, on sensors support
in QtMobility for BB10, on Windows and Windows CE features and
+1
On Tuesday, July 21, 2015 2:27 PM, Giuseppe D'Angelo
giuseppe.dang...@kdab.com wrote:
Hi,
I'd like to nominate Sérgio Martins for the Approver status in the Qt
project.
In the last years Sérgio has pushed lots of patches in a number of
components: he worked on the QNX/BB
On Tuesday 21 July 2015 13:27:51 Giuseppe D'Angelo wrote:
Hi,
I'd like to nominate Sérgio Martins for the Approver status in the Qt
project.
Oh, he's not an approver, yet? And here I was wondering why I only ever got +1
from him :)
+1
(Disclaimer: he's a colleague of mine at KDAB.)
Same
Hey,
It's juts me or CI is broken again? I'm trying to push a two patches[0] for a
few days with no luck ...
Cheers,
BogDan.
[0] https://codereview.qt-project.org/#/c/120757/
https://codereview.qt-project.org/#/c/120756/
___
Development mailing list
Is it obvious that the Qt 5.4.1 version installed by the system on a KDE
machine is binary incompatible to a locally compiled Qt 5.5.0?
That they are binary incompatible is shown by sporadic QtCreator crashes:
https://bugs.kde.org/show_bug.cgi?id=347524
2015-07-20 21:26 GMT+02:00 Thiago Macieira thiago.macie...@intel.com:
Aside from the variadic and the templateness, what's the difference?
The templateness changes how a type different than the vector's type gets
constructed (it might undergo a conversion first). But assuming I am
pushing
On Tuesday 21 July 2015 11:23:26 Allan Sandfeld Jensen wrote:
On Monday 20 July 2015, Marc Mutz wrote:
https://codereview.qt-project.org/121810
So start using qMove() or pass temporaries in your QVector::append()
calls.
Are we also using move internally when resizing and detaching?
http://testresults.qt.io/ci/QtXmlPatterns_dev_Integration/build_00123/macx-clang_no-framework_OSX_10.8/log.txt.gz
http://testresults.qt.io/ci/QtXmlPatterns_dev_Integration/build_00125/macx-clang_developer-build_OSX_10.9/log.txt.gz
Both failed at:
+ /work/build/qt/qtbase/configure -top-level
On 2015-07-21 01:06, Thiago Macieira wrote:
On Tuesday 21 July 2015 02:26:41 Kevin Kofler wrote:
For the implicitly shared data types, QList actually does NOT add another
layer of indirection (as documented: If T is itself a pointer type or a
basic type that is no larger than a pointer, or
69 matches
Mail list logo
