Re: [Development] QList for Qt 6
On 12/06/2019 18.14, Matthew Woehlke wrote:
> On 22/05/2019 12.41, Konstantin Tokarev wrote:
>> In the latter QList can be replaced with
>> std::vector> or QVector>
>
> No, it can't. `QList` has value semantics w.r.t. `T`. Your
> "alternatives" have pointer semantics.
And, to be clear... while having to write `*` and `->` is annoying, it
gets worse:
good_list.append(value);
// Never mind that we can't 'append'...
bad_list.emplace_back(new /* AIEE! */ value_t{value});
bad_list.emplace_back(std::make_unique(value));
...and worse:
auto evil = std::move(bad_list[i]);
bad_list[i]->frob();
A `QList` *always* has a value at a valid index. Your proposed
"alternatives" don't have that guarantee.
A `vector>` is simply **NOT** a replacement for
`QArrayList`. Period.
--
Matthew
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QList for Qt 6
(Sorry for not chiming in earlier, this was hidden wy at the top of my spool where I didn't notice there were unread messages.) On 22/05/2019 09.49, Lars Knoll wrote: > Let’s conclude the topic of QList. I do see the concern about silent > source breakages. Here’s what we’ll (I’ll) do then for Qt 6: > > 1. Rename QList to QArrayList and make QList an alias to QArrayList +lots. I have (grudgingly) been slowly moving toward using QVector more, but I still think there are legitimate cases when it makes sense to avoid copies-during-resizing. And, of course, there are times when one needs reference stability. I don't want to lose that container. It would be helpful to have a QArrayList that *always* uses indirect storage, and to have a clazy check for use of QArrayList where QVector is almost certainly a better choice (e.g. at least all cases where QList would not use indirect storage, and possibly with some heuristic for "small" and movable types). > 2. Move QStringList and QByteArrayList over to inherit from QVector (that > should be source compatible) +1. > 7. Make the implementation of QArrayList fully inline and deprecate the class. -lots, as long as Qt has container classes. (I still want an STL version of QArrayList, also...) However, QList should be deprecated. On 22/05/2019 12.41, Konstantin Tokarev wrote: > In the latter QList can be replaced with > std::vector> or QVector> No, it can't. `QList` has value semantics w.r.t. `T`. Your "alternatives" have pointer semantics. -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] unique_ptr and Qt, Take 2
On 03/05/2019 15.13, Thiago Macieira wrote: > On Friday, 3 May 2019 12:04:40 PDT Giuseppe D'Angelo via Development wrote: >> Anyhow, I too feel that we may need a dedicated smart pointer class for >> this, to catch all the corner cases and allow the existing flow of >> >> 1) create something >> 2) (re)parent it >> 3) keep using that something via a non-owning pointer. Or... just don't do that? I can't recall that I've *ever* had problems with QObject ownership. Generally, if you follow three rules: - If you create an object on the stack, either don't parent it or ensure its parent outlives it. (Usually not hard!) - If you create an object with `new`, **create** it with a parent. - Otherwise use a smart pointer (QScopedPointer or QSharedPointer)¹. ...you just won't have problems. (¹ These days, you can also add "or STL equivalents".) > Same here. I think Daniel is on to something and we really should explore > having smart pointers in Qt 6, but at this point I'm not convinced > std::unique_ptr alone is it. I'd like to see what we could achieve with a > QObject-specific smart pointer that understood ownership-taking functions > (setParent, addWidget, etc.) and observing-only API (like connect()). Idea: make this hypothetical pointer be a QObject that initially "owns" the object to which it points. If the object is reparented, the pointer will stop "owning" it but will still have the reference. (Not an optimal implementation, but could be easily implemented as a proof of concept.) -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposing CMake as build tool for Qt 6
Am 12.06.19 um 12:45 schrieb Christian Gagneraud: > On Fri, 7 Jun 2019 at 03:31, Alexandru Croitor > wrote: >> On 6. Jun 2019, at 16:48, Christian Gagneraud wrote: >> On Fri, 7 Jun 2019 at 02:25, Simon Hausmann wrote: >> Am 06.06.19 um 16:17 schrieb Christian Gagneraud: >> On Fri, 7 Jun 2019 at 02:08, Simon Hausmann wrote: >> Am 06.06.19 um 15:52 schrieb Christian Gagneraud: >> On Fri, 7 Jun 2019 at 01:35, Bogdan Vatra via Development >> wrote: > [what a beautiful thread, flatten by HTML top posting where no one can > understand the history of this discussion] > >> What metrics do you expect? >> With the time I had available, I discovered some issues regarding iOS + >> CMake, but nothing insurmountable. >> I gave my analysis. We (people working on the CMake port) feel it's possible >> to do. >> Now it's just a matter of getting to do it. But we still have other things >> to do first. > BTW, can cmake "out of the box" deal with: > https://doc.qt.io/qt-5/qtremoteobjects-repc.html > https://doc.qt.io/QtQuickCompiler/ > https://doc.qt.io/qtforpython/shiboken2/shibokenmodule.html > > Last time i checked none of these were supported. QtRemoteObjects has come with CMake support since its initial release with Qt 5.9.0. According to git log, Kevin Funk implemented it. The QtQuickCompiler has come with CMake support since version 2.0 released in 2014. The git history for that is not public, but I know it because I wrote it myself. Qt For Python uses CMake as its build system and it supports running shiboken from your project to generate type information and bindings. It's not very convenient from what I can tell, but it works. The docs are referring to it here https://doc.qt.io/qtforpython/shiboken2/samplebinding.html#building and the actual code is located in the pyside-setup repository under examples. > Yes, qmake support is "hackish", but that is not a good reason to > justify the near-zero support of cmake. The above at least is certainly not "near-zero". > And let me diverge a little bit, whatever the build system chosen by > Qt *developers*, Qt *users* should still be free to choose their own > build system. I'm including both open source users and paid customers. > That is: however *you* (qt developers) decide to use as your build > system shouldn't impact what *I* (as a Qt user) decide to use as my > own build system. > For example, you'll have to support qmake for years to come... You > like it or not. I tend to agree with that. At the moment this is primarily a decision for Qt development itself. Simon ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Views
On 6/12/19 10:28 AM, Mutz, Marc via Development wrote: > On 2019-06-12 09:20, Ulf Hermann wrote: >>> I don't think that (non-)COW is a problem in the scenario under >>> discussion. >> >> Having the thing COW makes the porting simpler at the cost of suboptimal >> performance. If we wrote a COW container as a drop-in replacement for >> QMap or QHash with equivalent behavior we could just s/QMap/QFlatMap/g >> in Qt code and the issue would largely be solved. > > As I said earlier: there's no alternative to thinking. There's no one > container that fits all use-cases. QFlatMap isn't it, either. It has > linear insertion behaviour, and it invalidates iterators on remove. You > need to analyse each use of QMap before replacing it with a QFlatMap (or > an unsorted vector, or a C array with the key as an index, or...). > > Get the idea out of your collective heads that we just need QFlatMap and > everything will be solved. For some code, yes. Just like QMap is the > correct container for some code already. But s/QMap/QFlatMap/ is just as > wrong as using QMap just because you need an associative container was > in the first place. I have to agree with Marc here. *Every* replacement must be checked manually whether the simple s/QMap/QFlatMap/ suffices or a more involved change is necessary. I believe many cases would be easily portable, but there will still be spots left where a raw sorted vector is the right approach - or another abstraction. Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposing CMake as build tool for Qt 6
On Fri, 7 Jun 2019 at 03:31, Alexandru Croitor wrote: > On 6. Jun 2019, at 16:48, Christian Gagneraud wrote: > On Fri, 7 Jun 2019 at 02:25, Simon Hausmann wrote: > Am 06.06.19 um 16:17 schrieb Christian Gagneraud: > On Fri, 7 Jun 2019 at 02:08, Simon Hausmann wrote: > Am 06.06.19 um 15:52 schrieb Christian Gagneraud: > On Fri, 7 Jun 2019 at 01:35, Bogdan Vatra via Development > wrote: [what a beautiful thread, flatten by HTML top posting where no one can understand the history of this discussion] > What metrics do you expect? > With the time I had available, I discovered some issues regarding iOS + > CMake, but nothing insurmountable. > I gave my analysis. We (people working on the CMake port) feel it's possible > to do. > Now it's just a matter of getting to do it. But we still have other things to > do first. BTW, can cmake "out of the box" deal with: https://doc.qt.io/qt-5/qtremoteobjects-repc.html https://doc.qt.io/QtQuickCompiler/ https://doc.qt.io/qtforpython/shiboken2/shibokenmodule.html Last time i checked none of these were supported. Yes, qmake support is "hackish", but that is not a good reason to justify the near-zero support of cmake. And let me diverge a little bit, whatever the build system chosen by Qt *developers*, Qt *users* should still be free to choose their own build system. I'm including both open source users and paid customers. That is: however *you* (qt developers) decide to use as your build system shouldn't impact what *I* (as a Qt user) decide to use as my own build system. For example, you'll have to support qmake for years to come... You like it or not. Chris ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
On 11/06/2019 22:13, André Pönitz wrote: Can we at the very least agree that each party is allowed to use the same*pattern* of reasoning in this discussion, no matter on how much merit we see in the individual argument? I'd rather avoid using any logical fallacy when possible, instead of doubling down (... or actually decupling down). My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] How to port from Q_FOREACH to range-based for
Mutz, Marc via Development wrote: > This is a bit like the Fridays for Future generation clash: the new > developer asks "why is there Q_FOREACH if there's ranged-for?" and the > older devs answer: "because I wants my SUV, erhm, I mean Q_FOREACH". The difference is that Q_FOREACH does not destroy our planet as SUVs (and cars in general, even electric cars as long as the electricity production from renewable energy sources is stuck at its current insufficient capacity) and other CO₂ emitters do. A future without cars also needs to be a future without car analogies. :-) Kevin Kofler (who supports the Fridays for Future movement) ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] How to port from Q_FOREACH to range-based for
On 2019-06-12 08:23, Philippe wrote: On Wed, 12 Jun 2019 07:54:29 +0200 Nicolas Arnaud-Cormos via Development wrote: Whenever Qt is adding a new feature there's a teachability issue that needs to be handled. Any duplication with the C++ standard adds cognitive load to students. One could dismiss that by saying just use the Qt solution, but it would be hiding himself in a box: I'm working on customer codes (not mine), Except that in this case, we are speaking about a side-effect of Copy-on-write, and this technique is an essential one to know, even independently from Qt, one technique that any student should be aware of :) https://en.wikipedia.org/wiki/Copy-on-write Have you run clazy on something like Qt 5.4, ie. before clazy was first run on Qt? One would think that if any student should be aware of CoW, so should any Qt dev. You're in for a surprise! ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Views
On 2019-06-12 09:20, Ulf Hermann wrote: I don't think that (non-)COW is a problem in the scenario under discussion. Having the thing COW makes the porting simpler at the cost of suboptimal performance. If we wrote a COW container as a drop-in replacement for QMap or QHash with equivalent behavior we could just s/QMap/QFlatMap/g in Qt code and the issue would largely be solved. As I said earlier: there's no alternative to thinking. There's no one container that fits all use-cases. QFlatMap isn't it, either. It has linear insertion behaviour, and it invalidates iterators on remove. You need to analyse each use of QMap before replacing it with a QFlatMap (or an unsorted vector, or a C array with the key as an index, or...). Get the idea out of your collective heads that we just need QFlatMap and everything will be solved. For some code, yes. Just like QMap is the correct container for some code already. But s/QMap/QFlatMap/ is just as wrong as using QMap just because you need an associative container was in the first place. Thanks, Marc ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposing CMake as build tool for Qt 6
Even if modules were available (and stable) in at least mainline versions
of {clang, gcc, msvc} in a year (which I don't think they will), Qt would
have to get modularized to actually be able to reap the benefits of modules
(given the strong feelings in the "deprecations" thread, we can expect
mid-2050 for that one maybe ? e.g. for now Qt 6 will be AFAIK on a C++17
baseline... if we consider that it took up to Qt 5.7, released in 2016, to
require a C++11 compiler to build, you can see that `import QString;` in
qobject.h is still a decade away :-)).
So I really think that the time saved by PCH today, which is for me at
least a good few minutes per Qt build, is important to keep.
Besides, current implementations of modules aren't faster than a good PCH
(or at least they weren't last time I checked clang's).
Best,
Jean-Michaël
On Tue, Jun 11, 2019 at 5:50 PM Matthew Woehlke
wrote:
> On 06/06/2019 09.23, Simon Hausmann wrote:
> > Regarding PCH, it seems that right now it would be easiest to
> > include something like https://github.com/sakra/cotire . Patches are
> > welcome to integrate this or alternatively work with upstream CMake
> > for a built-in solution.
>
> Considering that modules are coming, I wonder how much sense it makes to
> keep working on PCH?
>
> --
> Matthew
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Views
> I don't think that (non-)COW is a problem in the scenario under > discussion. Having the thing COW makes the porting simpler at the cost of suboptimal performance. If we wrote a COW container as a drop-in replacement for QMap or QHash with equivalent behavior we could just s/QMap/QFlatMap/g in Qt code and the issue would largely be solved. Ulf ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
