On Donnerstag, 30. März 2017 08:32:24 CEST Marc Mutz wrote:
> On Thursday 30 March 2017 08:18:52 Olivier Goffart wrote:
> > On Donnerstag, 30. März 2017 07:20:11 CEST Marc Mutz wrote:
> > > On Wednesday 29 March 2017 22:12:30 Thiago Macieira wrote:
> > > > On quarta-feira, 29 de março de 2017 11:11
On Thursday 30 March 2017 08:18:52 Olivier Goffart wrote:
> On Donnerstag, 30. März 2017 07:20:11 CEST Marc Mutz wrote:
> > On Wednesday 29 March 2017 22:12:30 Thiago Macieira wrote:
> > > On quarta-feira, 29 de março de 2017 11:11:58 PDT Marc Mutz wrote:
> > > > Keyword: inline namespaces. This is
On Donnerstag, 30. März 2017 07:20:11 CEST Marc Mutz wrote:
> On Wednesday 29 March 2017 22:12:30 Thiago Macieira wrote:
> > On quarta-feira, 29 de março de 2017 11:11:58 PDT Marc Mutz wrote:
> > > Keyword: inline namespaces. This is the C++ mechanism for API
> > > versioning. It allows to make tha
On Wednesday 29 March 2017 22:12:30 Thiago Macieira wrote:
> On quarta-feira, 29 de março de 2017 11:11:58 PDT Marc Mutz wrote:
> > Keyword: inline namespaces. This is the C++ mechanism for API
> > versioning. It allows to make that totally transparent. Why you find
> > that so odd as to be lacking
On quarta-feira, 29 de março de 2017 08:44:35 PDT Thiago Macieira wrote:
> Without destructive moves:
> 1) allocate new block
> 2) move each element (constructor is noexcept, good)
> -> could be a memcpy + memset, but isn't...
> 3) destroy each element (refcount is checked every time!)
> 4) d
30.03.2017, 00:17, "Philippe" :
>> I would really, really like to know why QVector is easier to use?
>
> Following common methods are immediate. With std::vector, you need to
> add boilerplate code to achieve the same.
>
> QVector::insert
> QVector::remove
> QVector::value(int i, const T &defaul
> I would really, really like to know why QVector is easier to use?
Following common methods are immediate. With std::vector, you need to
add boilerplate code to achieve the same.
QVector::insert
QVector::remove
QVector::value(int i, const T &defaultValue)
QVector::move
QVector::contains
QVector:
On quarta-feira, 29 de março de 2017 11:11:58 PDT Marc Mutz wrote:
> Keyword: inline namespaces. This is the C++ mechanism for API
> versioning. It allows to make that totally transparent. Why you find
> that so odd as to be lacking for words is beyond me.
Inline namespaces do not solve the binary
On 2017-03-29 14:11, Marc Mutz wrote:
> On 2017-03-29 18:57, Matthew Woehlke wrote:
>> I think the main reason some many people disagree with you on CoW and
>> related subjects is because you put performance above all else,
>> including correctness and ease of use.
>
> Interesting. My criticism of
On 2017-03-29 18:57, Matthew Woehlke wrote:
On 2017-03-29 11:28, Marc Mutz wrote:
Deep-copying does not write to the source object, and any number of
cores can share read access for a given cache line, each with its own
copy, so deep-copying scales linearly with the number of cores.
Deep copyi
On Mittwoch, 29. März 2017 11:53:16 CEST Ville Voutilainen wrote:
> On 29 March 2017 at 12:49, Marc Mutz wrote:
> > This is probably one of the most important things. Ville asked on std-
> > proposals to show hard numbers. You don't need hard numbers. You just need
> > to superficially look at QVe
On 2017-03-29 11:28, Marc Mutz wrote:
> Deep-copying does not write to the source object, and any number of
> cores can share read access for a given cache line, each with its own
> copy, so deep-copying scales linearly with the number of cores.
Deep copying is vectorized? Really?
> On 2017-03-29
On quarta-feira, 29 de março de 2017 08:44:35 PDT Thiago Macieira wrote:
> Ok, so I guess we can easily benchmark this by making the Qt containers
> forget about the movable property, then benchmark the load time of a large
> application like Qt Creator. Unfortunately, this means recompiling
> ever
On 19 March 2017 at 20:01, Thiago Macieira
mailto:thiago.macie...@intel.com>> wrote:
>> The rules are that only Qt Company people can import 3rdparty code, so I know
>> I am not responsible.
>>
>> Who do I assign the bug to?
>> https://bugreports.qt.io/browse/QTBUG-59586
QUIP 4 (see below) should
On quarta-feira, 29 de março de 2017 02:53:16 PDT Ville Voutilainen wrote:
> The hard number we still need is this:
> 1) how much of a performance difference does a destructive move make
QVector is all you need to see that.
Without destructive moves:
1) allocate new block
2) move each element (
On 2017-03-29 16:41, Matthew Woehlke wrote:
On 2017-03-29 07:26, Marc Mutz wrote:
That brings us straight back to the fundamental question: Why can the
C++
world at large cope with containers that are not CoW and Qt cannot?
The only
answer I have is "because Qt never tried". And that's the end
On 2017-03-29 07:26, Marc Mutz wrote:
> That brings us straight back to the fundamental question: Why can the C++
> world at large cope with containers that are not CoW and Qt cannot? The only
> answer I have is "because Qt never tried". And that's the end of it. I have
> pointed to Herb's strin
On 29 March 2017 at 15:53, Olivier Goffart wrote:
> On Mittwoch, 29. März 2017 13:33:12 CEST Philippe wrote:
>> On Wed, 29 Mar 2017 10:39:42 +0200
>>
>> Olivier Goffart wrote:
>> > I don't think we need QArrayList. As you said, it's not often used (only
>> > one known use?). and QToolBox is not
On Mittwoch, 29. März 2017 13:33:12 CEST Philippe wrote:
> On Wed, 29 Mar 2017 10:39:42 +0200
>
> Olivier Goffart wrote:
> > I don't think we need QArrayList. As you said, it's not often used (only
> > one known use?). and QToolBox is not even using the implicit sharing, so
> > it could easily b
On 29 March 2017 at 15:31, Marc Mutz wrote:
>> All this makes me wonder why we should have QArrayList at all. If it's
>> slated for immediate deprecation,
>
> I said _I_ would immediately deprecate it. Wether we do depends on a lot of
> other things, too. E.g. what will happen to our other contain
On Wednesday 29 March 2017 14:20:42 Giuseppe D'Angelo wrote:
> Il 29/03/2017 13:27, Marc Mutz ha scritto:
> > On Wednesday 29 March 2017 11:37:57 Ville Voutilainen wrote:
> >> Let me take a step back. Do we need a list container that is always
> >> indirect regardless of
> >> the element type and u
On Wednesday 29 March 2017 13:39:34 Ville Voutilainen wrote:
> > Bottomline: don't expect me to support any form of implicit sharing. The
> > answer will always be: because you should use explicit sharing.
> >
> > This is why I see QArrayList as a phase-out vehicle for QList, not as a
> > fancy ne
Il 29/03/2017 13:27, Marc Mutz ha scritto:
> On Wednesday 29 March 2017 11:37:57 Ville Voutilainen wrote:
>> Let me take a step back. Do we need a list container that is always
>> indirect regardless of
>> the element type and uses implicit sharing?
>
> We have that: it's called QLinkedList.
Or,
On Wednesday 29 March 2017 13:33:12 Philippe wrote:
> On Wed, 29 Mar 2017 10:39:42 +0200
>
> Olivier Goffart wrote:
> > I don't think we need QArrayList. As you said, it's not often used (only
> > one known use?). and QToolBox is not even using the implicit sharing, so
> > it could easily be por
On 19 March 2017 at 20:01, Thiago Macieira
wrote:
> The rules are that only Qt Company people can import 3rdparty code, so I
> know
> I am not responsible.
>
> Who do I assign the bug to?
> https://bugreports.qt.io/browse/QTBUG-59586
For QTBUG-59586, I have https://codereview.qt-project.org/189
> That brings us straight back to the fundamental question: Why can the C++
> world at large cope with containers that are not CoW and Qt cannot? The only
> answer I have is "because Qt never tried".
I started using STL 20 years ago, and Qt 8 years ago. Both intensively.
My experience is simple:
On 29 March 2017 at 14:26, Marc Mutz wrote:
>> If I start using QArrayList today, and it's immediately
>> deprecated, what
>> should I use instead? vector>? That doesn't
>> do implicit sharing,
>
> Because it's you who asks: if CoW is so super-important, why did the committee
> drop support for Co
On Wed, 29 Mar 2017 10:39:42 +0200
Olivier Goffart wrote:
> I don't think we need QArrayList. As you said, it's not often used (only one
> known use?). and QToolBox is not even using the implicit sharing, so it could
> easily be ported so std::vector>
When you need an index-based container, t
On Wednesday 29 March 2017 11:37:57 Ville Voutilainen wrote:
> Let me take a step back. Do we need a list container that is always
> indirect regardless of
> the element type and uses implicit sharing?
We have that: it's called QLinkedList.
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschl
On Wednesday 29 March 2017 11:37:57 Ville Voutilainen wrote:
> On 29 March 2017 at 11:29, Marc Mutz wrote:
> > On Wednesday 29 March 2017 09:37:04 Marc Mutz wrote:
> >> Please approve the former, or propose something else.
> >
> > I actually meant this ^^. Approve or _propose_ something else.
> >
On 29 March 2017 at 12:49, Marc Mutz wrote:
> This is probably one of the most important things. Ville asked on std-
> proposals to show hard numbers. You don't need hard numbers. You just need to
> superficially look at QVector. The compiler generally cannot proove
> that the call to QArrayData::
On Monday 20 March 2017 22:19:11 Thiago Macieira wrote:
> Em sábado, 18 de março de 2017, às 14:20:49 PDT, Thiago Macieira escreveu:
> > == Containers ==
> >
> > And then there's what to do with the containers. Here's where Marc's
> > opinion and mine differ considerably. Aside from the need to ma
On 29 March 2017 at 11:29, Marc Mutz wrote:
> On Wednesday 29 March 2017 09:37:04 Marc Mutz wrote:
>> Please approve the former, or propose something else.
>
> I actually meant this ^^. Approve or _propose_ something else.
>
> Just to be clear on this: I'm ready to do the work as outlined. But I w
On вторник, 28 марта 2017 г. 01:18:18 EEST Rafael Roquetto wrote:
>> It clearly has nothing to do anymore with the vector from my geometry
>> classes. I don't know why it received the named 'vector' in first
>> place,
It's "carrier" in Latin; a vector carries several numbers.
Geometry was a late-
On Mittwoch, 29. März 2017 09:37:04 CEST Marc Mutz wrote:
> To bring this thread back on-topic:
>
> I have prepared a patch that implements QArrayList as outlined below (as a
> template alias): https://codereview.qt-project.org/188938
>
> The only well-known user of stable references into QList,
On Wednesday 29 March 2017 09:37:04 Marc Mutz wrote:
> Please approve the former, or propose something else.
I actually meant this ^^. Approve or _propose_ something else.
Just to be clear on this: I'm ready to do the work as outlined. But I will
most certainly not write a QArrayList-as-a-class-
To bring this thread back on-topic:
I have prepared a patch that implements QArrayList as outlined below (as a
template alias): https://codereview.qt-project.org/188938
The only well-known user of stable references into QList, QToolBox, is
"ported" here: https://codereview.qt-project.org/188941
37 matches
Mail list logo
