Re: [Development] Feature freeze next Tuesday

On Tuesday, 25 August 2020 23:46:41 PDT Lars Knoll wrote: > There are three areas that have asked for an exception to the freeze to > finish things that are still pending: > > * In QtCore, the Q*Iterables in qmetatype/qvariant > * Across Gui/Declarative/QuickControls the input system > * The new

Re: [Development] Important recent changes in QList/QString/QByteArray

On Tuesday, 1 September 2020 13:06:39 PDT Иван Комиссаров wrote: > Sorry, but you’re wrong here. Cppreference clearly says Cppreference is irrelevant. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering

Re: [Development] Important recent changes in QList/QString/QByteArray

Sorry, but you’re wrong here. Cppreference clearly says Invalidates iterators and references at or after the point of the erase, including the end() iterator. https://en.cppreference.com/w/cpp/container/vector/erase

Re: [Development] Important recent changes in QList/QString/QByteArray

On Tuesday, 1 September 2020 10:41:33 PDT Giuseppe D'Angelo via Development wrote: > This is the contract, and it's OK. I don't think however that this is > what was intended by OP. Rather, that calling a non-const function may > repack/reallocate a QCC (*), causing invalidation of all references

Re: [Development] Important recent changes in QList/QString/QByteArray

On Tuesday, 1 September 2020 10:46:21 PDT Giuseppe D'Angelo via Development wrote: > Pedantically: if any and all non-const function will invalidate > iterators, then calling any algorithm that takes an iterator range > becomes formally impossible (unless one obtains an iterator range in one >

Re: [Development] Important recent changes in QList/QString/QByteArray

Il 01/09/20 19:31, Thiago Macieira ha scritto: There's no violation. Your code was incorrect in the past, it just happened to work. This isn't true... Assume any and all non-const function will invalidate iterators. ... because this is sketchy. It has never been 100% documented, but

Re: [Development] Important recent changes in QList/QString/QByteArray

> There's no violation. Your code was incorrect in the past, it just happened to work. I have to remind you about the Qt5.5 and the QDebug behaviour change that had to be rolled back because of the backlash. This has ramifications way bigger than a simple logging breakage. If a mission critical

Re: [Development] Important recent changes in QList/QString/QByteArray

Il 01/09/20 19:33, Thiago Macieira ha scritto: All non-const functions that may detach should be coded so they DO detach. That is, after any and all non-const functions, the refcount of the container should be 1. This is the contract, and it's OK. I don't think however that this is what was

Re: [Development] Important recent changes in QList/QString/QByteArray

On Tuesday, 1 September 2020 08:53:36 PDT Giuseppe D'Angelo via Development wrote: > So, now, formally, std::sort(v.begin(), v.end()) risks undefined > behavior? E.g. begin() returns the begin iterator without touching > anything, but end() decides to invalidate all the iterators. We've seen

Re: [Development] Important recent changes in QList/QString/QByteArray

On Tuesday, 1 September 2020 09:05:48 PDT NIkolai Marchenko wrote: > Wait what? The switch to Qt6 was supposed to become a painless process yet > you're introducing important and hard to notice in real code changes that > can result in undefined behaviour? > What? WHAT?! There's no violation.

Re: [Development] Is qsizetype *documented* to be ptrdiff_t?

On Tuesday, 1 September 2020 08:44:07 PDT Giuseppe D'Angelo via Development wrote: > Il 01/09/20 16:23, Thiago Macieira ha scritto: > > So even if you use %td or %zd, GCC will complain in one of three different > > platform configurations (namely, 64-bit Unix). > > Pedantically, do we need the

Re: [Development] New property system

> On 1 Sep 2020, at 16:12, Thiago Macieira wrote: > > On Tuesday, 1 September 2020 02:54:49 PDT Lars Knoll wrote: >>> If it's only for compatibility, what should one write in the Q_PROPERTY >>> header for new properties? >> >> As said, it’s for both old and new properties in QObjects. What you

Re: [Development] Important recent changes in QList/QString/QByteArray

> A more subtle issue concerns the users of QVector. Wait what? The switch to Qt6 was supposed to become a painless process yet you're introducing important and hard to notice in real code changes that can result in undefined behaviour? What? WHAT?! On Tue, Sep 1, 2020 at 6:58 PM Giuseppe

Re: [Development] Important recent changes in QList/QString/QByteArray

Hi, Thanks for the heads up! Il 31/08/20 13:50, Andrei Golubev ha scritto: The invalidation existed before for cases when a container could detach (due to copy-on-write) or reallocate (due to growing or squeezing). This sounds incorrect? Which invalidation did happen due to COW? Now this

Re: [Development] Is qsizetype *documented* to be ptrdiff_t?

Il 01/09/20 16:23, Thiago Macieira ha scritto: So even if you use %td or %zd, GCC will complain in one of three different platform configurations (namely, 64-bit Unix). Pedantically, do we need the PRIxQSS (?) macro and friends to use qsizetype into qWarning etc.? Thanks, -- Giuseppe

Re: [Development] Is qsizetype *documented* to be ptrdiff_t?

On Monday, 31 August 2020 04:55:32 PDT Giuseppe D'Angelo via Development wrote: > Quick question (before Hyrum's law kicks in): qsizetype is currently > defined as ptrdiff_t, but is it documented to be so? > > For instance, is one supposed to print it in printf using %td? It's always the same

Re: [Development] New property system

On Tuesday, 1 September 2020 02:54:49 PDT Lars Knoll wrote: > > If it's only for compatibility, what should one write in the Q_PROPERTY > > header for new properties? > > As said, it’s for both old and new properties in QObjects. What you need to > do to convert a property and make it bindable is

Re: [Development] Is qsizetype *documented* to be ptrdiff_t?

> On 31 Aug 2020, at 13:55, Giuseppe D'Angelo via Development > wrote: > > Quick question (before Hyrum's law kicks in): qsizetype is currently defined > as ptrdiff_t, but is it documented to be so? It is defined as qint64, which is not always ptrdiff_t. I proposed to Thiago to change that,

Re: [Development] Feature freeze next Tuesday

> On 1 Sep 2020, at 12:17, Giuseppe D'Angelo via Development > wrote: > > On 01/09/2020 11:20, Maurice Kalinowski wrote: >>> * QIM::multidata >> https://codereview.qt-project.org/c/qt/qtbase/+/302905 >> Currently +2, waiting for integration >>> * QKeyCombination + removal of

Re: [Development] Feature freeze next Tuesday

On 01/09/2020 11:20, Maurice Kalinowski wrote: * QIM::multidata https://codereview.qt-project.org/c/qt/qtbase/+/302905 Currently +2, waiting for integration * QKeyCombination + removal of operator+(QFlags, *) https://codereview.qt-project.org/c/qt/qtbase/+/297566 Currently +1,

[Development] Reminder: Feature freeze today

Hi everybody, This is your friendly reminder that we are now in feature freeze for Qt 6. There are a couple of exceptions that have been listed in my mail last week. If you have a single change or two that has been reviewed but is simply waiting to get through CI you can still finish those up

Re: [Development] New property system

> On 31 Aug 2020, at 06:17, Thiago Macieira wrote: > > On Wednesday, 26 August 2020 00:18:49 PDT Lars Knoll wrote: >> To summarise the advantages of the redesigned system: >> >> * Very little memory overhead if bindings aren’t used >> * Very low runtime overhead if bindings aren’t used >> *

Re: [Development] Feature freeze next Tuesday

For better discussion, let's have a look at the existing patches: > * QIM::multidata https://codereview.qt-project.org/c/qt/qtbase/+/302905 Currently +2, waiting for integration > * QKeyCombination + removal of operator+(QFlags, *) https://codereview.qt-project.org/c/qt/qtbase/+/297566

Re: [Development] Important recent changes in QList/QString/QByteArray

Hey, ASan for x86 Release targets is available in MSVC since  https://devblogs.microsoft.com/cppblog/addresssanitizer-asan-for-windows-with-msvc/ , and recently also for x64 + Debug builds https://devblogs.microsoft.com/cppblog/asan-for-windows-x64-and-debug-build-support/ To add some details.

Re: [Development] Feature freeze next Tuesday

Hi, Do you have some estimate how long time is needed to get these in? Also, do you foresee any issues these changes may cause to others? Yours, Tuukka On 1.9.2020, 11.01, "Development on behalf of Giuseppe D'Angelo via Development" wrote: Il 26/08/20 08:46, Lars Knoll ha

Re: [Development] New property system

On Wed, 26 Aug 2020 at 09:20, Lars Knoll wrote: > > Hi all, > > After the long discussions a few weeks back about the new property system and > some trial to port the existing properties over to the new system, it became > somewhat clear to me that the approach we had tried so far won’t work

Re: [Development] qsizetype and classes working with QStrings or QList

> On 27 Aug 2020, at 08:04, Giuseppe D'Angelo via Development > wrote: > > Hi, > > Il 27/08/20 02:46, Thiago Macieira ha scritto: >> A QListView of 2 billion lines with where each line is a QString one >> to 7 characters in length would be 2G * (24 + 32) = 96 GB of memory use. >> QListWidget's

Re: [Development] QHelpEngineCore::documentsForIdentifier

Hi Martin, sorry for not answering earlier. I've just prepared a patch that should fix it. The assumption before was that at some point the default for using new filter engine will change to true. However, since it didn't happen so far, I'm providing a full fix for old filtering system, too.

[Development] Important recent changes in QList/QString/QByteArray

Hello all, Over the last week I pushed several patches to enable prepend optimization in some core containers, namely, QList, QString, QByteArray. In the light of these changes, there may occur new subtle issues in your code. New model --- In a nutshell, prepend optimization code does some

[Development] Is qsizetype *documented* to be ptrdiff_t?

Quick question (before Hyrum's law kicks in): qsizetype is currently defined as ptrdiff_t, but is it documented to be so? For instance, is one supposed to print it in printf using %td? Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a

[Development] Important recent changes in QList/QString/QByteArray

Hello all, Over the last week I pushed several patches to enable prepend optimization in some core containers, namely, QList, QString, QByteArray. In the light of these changes, there may occur new subtle issues in your code. New model --- In a nutshell, prepend optimization code does some

Re: [Development] Feature freeze next Tuesday

Il 26/08/20 08:46, Lars Knoll ha scritto: I would hope that there are no other exceptions required. If something is not done, but can easily be pushed to 6.1, you know what to do. If anybody knows about something else that can’t be pushed please talk to me, so we can figure out what to do

Re: [Development] QHelpEngineCore::documentsForIdentifier

Hi Martin, sorry for not answering earlier. I've just prepared a patch that should fix it. The assumption before was that at some point the default for using new filter engine will change to true. However, since it didn't happen so far, I'm providing a full fix for old filtering system, too.

Re: [Development] New property system

On Wednesday, 26 August 2020 00:18:49 PDT Lars Knoll wrote: > To summarise the advantages of the redesigned system: > > * Very little memory overhead if bindings aren’t used > * Very low runtime overhead if bindings aren’t used > * Binding support can be added to properties in QObjects in a