Re: [Development] QList

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

Re: [Development] Wishes for C++ standard or compilers

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)

Re: [Development] QList

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 >

Re: [Development] QList

> 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 ) QVector::move QVector::contains

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] Wishes for C++ standard or compilers

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

Re: [Development] QList

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

Re: [Development] Wishes for C++ standard or compilers

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 >

Re: [Development] Who's responsible for 3rdparty these days (QTBUG-59586)?

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? >>

Re: [Development] Wishes for C++ standard or compilers

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

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] QList

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 >

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] Who's responsible for 3rdparty these days (QTBUG-59586)?

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

Re: [Development] QList

> 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

Re: [Development] QList

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

Re: [Development] QList

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>

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] Wishes for C++ standard or compilers

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

Re: [Development] Wishes for C++ standard or compilers

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

Re: [Development] QList

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

Re: [Development] Etymological digression from QList discussion

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

Re: [Development] QList

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,

Re: [Development] QList

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: