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 o
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 tes
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 boun
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 QMap > X>.
> Certainly possible to do, but sometimes quite awkward depending on the
> situation.
Agreed.
> > I don't see the need to do the same
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 QMap 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 th
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 ju
On Tuesday 21 July 2015 18:10:27 Ansel Sermersheim wrote:
> The most common use case of this is creating a QMap 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 suppor
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 qMa
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, expec
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 an
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 sugg
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
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 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 the terms of the
> licenses under
Il 21/07/2015 20:36, Marc Mutz ha scritto:
Best explained with some code:
See also Scott Meyer's keynote at MeetingC++ last year:
https://www.youtube.com/watch?v=smqT9Io_bKo around 19:00.
Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group
On Tue, Jul 21, 2015 at 10:26 PM, 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 the terms of the
> licenses under wh
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 fol
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,
> e
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
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 17:11:42 Bubke Marco wrote:
> Thiago Macieira
> > > 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 to keep the
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
On Tuesday 21 July 2015 20:11:33 Bubke Marco wrote:
> Gunnar Roth
>
> > > 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 neede
On Tuesday 21 July 2015 19:53:14 Gunnar Roth wrote:
> Hi Ansel.
>
> > Am 21.07.2015 um 19:06 schrieb Ansel Sermersheim :
> >
> > 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 clos
> Am 21.07.2015 um 20:11 schrieb Bubke Marco :
>
>
> Gunnar Roth
>>>
>>> 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)
> Am 21.07.2015 um 19:58 schrieb Milian Wolff :
>
> 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 J
On Tuesday 21 July 2015 19:11:42 Bubke Marco wrote:
> Thiago Macieira
>
> > On Tuesday 21 July 2015 16:14:18 Bubke Marco wrote:
> > > Thiago Macieira
> > >
> > > > > > Or like QString and QByteArray will be in Qt 6.
> > > > >
> > > > > Are these still implicitly shared?
> > > >
> > > > Yes, i
Gunnar Roth
> >
> > 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 alrea
> Am 21.07.2015 um 19:14 schrieb Matthew Woehlke :
>
> 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 is the push_back imp
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::
On Tue, Jul 21, 2015 at 12:49 PM 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) converts
Hi Ansel.
> Am 21.07.2015 um 19:06 schrieb Ansel Sermersheim :
>
> 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 licensed under GPL,LGPL
>
> 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,
Gu
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::vector. You've explained that emplace_back
> is efficient, but you haven't said whether push_back is as efficient, more
> efficient or le
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
> pus
Thiago Macieira
> On Tuesday 21 July 2015 16:14:18 Bubke Marco wrote:
> > Thiago Macieira
> >
> > > > > 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
> > > c
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
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
_LIBCPP_INLINE_VI
On Tuesday 21 July 2015 12:22:36 Matthew Woehlke wrote:
> std::vector 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.macieir
On Tuesday 21 July 2015 16:14:18 Bubke Marco wrote:
> Thiago Macieira
>
> > > > 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 conversi
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
Thiago Macieira
> > > 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 conversion?
___
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 who
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 alignof(voi
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 pressu
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 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.
>
> Ho
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 p
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 Archit
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
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 vie
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
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 fro
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 pointe
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 :
> Hey,
>
> It's juts me or CI is broken again? I'm trying to push a two patches[0] fo
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
+1
On Tuesday, July 21, 2015 2:27 PM, 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 platform plugin, on sensors su
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.)
+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/B
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 bugfixe
On 21/07/15 09:00, "Takao Fujiwara" 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 wil
Op 21-7-2015 om 11:55 schreef Bubke Marco:
>
>
> From: development-bounces+marco.bubke=theqtcompany@qt-project.org
> on behalf
> of Kevin Kofler
>> If you have large objects, and insert or remove items within the list,
>> QVector will have to move (or even copy&delete, if they're not movabl
From: development-bounces+marco.bubke=theqtcompany@qt-project.org
on behalf of
Kevin Kofler
> If you have large objects, and insert or remove items within the list,
> QVector will have to move (or even copy&delete, if they're not movable)
> large amounts of data. Unless you use a QVector
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 det
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?
`Allan
___
Development ma
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
https://bugreports.qt.io/browse/QTCREATORBUG
2015-07-20 21:26 GMT+02:00 Thiago Macieira :
> 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
> back a T, is there an
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
> >
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, s
70 matches
Mail list logo
