Re: [Development] Out of line move constructors
Il 14/09/20 23:48, Thiago Macieira ha scritto: It's not inline, it's because you didn't define it. To use the extern in the header, you need to add the definition to the .cpp, after the Private class was defined. That effectively means repeating the body of the destructor we extern'ed. So we'd probably need a macro to ensure that. As commented on the patch, this part of the story that eventually led to the design of QIntrusiveSharedDataPointer -- the previous incantations featured macros and the like, and the commit message talked about trouble in the presence of exported symbols, but I'm not sure what it was referring to. Does anyone remember? If it's no longer an issue, is pinning the smart pointer dtor the way we want to go? How to make it into a public API so that it's not just a Qt-specific trick? (After all, the smart pointers in question have public APIs) Thanks, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Out of line move constructors
Hi, Many pimpled types in Qt lack a move constructor. History: back in the day, when C++11 wasn't a requirement and binary compatibility between C++98/C++11 was to be kept, we had to implement C++11-only code (such as move operations) inline. This however isn't possible for move constructors if the type is implemented using pimpl (with or without refcounting). Coming 5.9, C++11 became a requirement. Still we didn't add move constructors for pimpled types; the rationale was that we wanted move operations to be inline. For refcounted types, the idea was to achieve that (I think) by using something like QIntrusiveSharedPointer instead of Q(E)SDP. Anyhow: is this still the policy, or do we want to start adding out of line move constructors? Thanks, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Important recent changes in QList/QString/QByteArray
On 10/09/2020 15:38, Ville Voutilainen wrote: The "flag" is basically "a call to reserve was made"? How do I clear the flag? Yes (CapacityReserved, in Qt 5). squeeze() / shrink_to_fit() were supposed to clear it. HTH, -- 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] Important recent changes in QList/QString/QByteArray
Il 10/09/20 08:48, Andrei Golubev ha scritto: That's the dilemma that Andrei was talking about. Either solution is valid and both have a way for you to tell QList to do what you want. Oh, but it's not a question of "if". It is already done in latest dev this way, the shrinking erase, I mean (not sure who was an author of the original change). But reallocating on erase still falls under the problem that it invalidates everything, including the part before the erased range. -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Important recent changes in QList/QString/QByteArray
Il 10/09/20 04:31, Thiago Macieira ha scritto: This is another against automatic shrinking; it may invalidate everything rather than just the erased area. I don't understand the "detach" part, is it about holding references across a detach, so they refer to the original container, not the detached one? That's not different from we always had, isn't it? It means that if you try to erase from a container that is currently shared, it will detach. When it does, the detached container's size will be evaluated in terms of the size of the container, not the capacity the shared container had. Why isn't the capacity carried across? QVector v; v.reserve(100); v.push_back(~~~); // fill it up // someone takes a copy auto v2 = v; // erase into the original v.erase(~~~); // now v's capacity is no longer reserved to be >= 100? 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Important recent changes in QList/QString/QByteArray
On 09/09/2020 10:55, Andrei Golubev wrote: Small update on QList::erase: the iterator invalidation model will be aligned with std::vector's erase (in progress of merging the change to dev and it got approved already). This means that, when erasing, only the iterators that correspond to erased elements and elements after them (until end()) will be invalidated*. The corner case is erasing from the beginning where formal definition seems to allow right-shifting erasure (feel free to prove me wrong) and the only concern I have is when someone holds QList::constData()/data() pointer, since this will be invalidated in the corner case. data() is invalidated if one erases begin(), so no problem. *- except when detach is necessary or shrinking happens This is another against automatic shrinking; it may invalidate everything rather than just the erased area. I don't understand the "detach" part, is it about holding references across a detach, so they refer to the original container, not the detached one? That's not different from we always had, isn't it? As to whether we should or should not shrink when erasing too many elements, there are clearly two opposite opinions (see the "replied to" conversation). My assumption would be that shrinking in erase has some justification (otherwise, why do it in the first place?). Thus, there are already Qt-relevant cases that benefit from having smaller memory footprint. On the other hand, "please do not free memory, I still need it" use-case is also justified. However, chances are that when you really need a certain memory to be allocated/preserved, there is a call to QList::reserve() prior to insertions/deletions. And since we do not shrink in case of reserved memory, users should be safe in this case, in general. Are the new behaviors autotested for all the leaf classes, incl. things like detaching a reserve()d container? The usual problem is that the code duplication in QVector/QString/QByteArray gave them completely different behaviors (there's a number of bug reports open). -- 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] Is qsizetype *documented* to be ptrdiff_t?
On 03/09/2020 08:54, Lars Knoll wrote: I think we have long in most of the important places today. I agree that adding long to the overload set is somewhat annoying, but it could be an inline method mapping to QIntegerForSize::type. Has anybody ever looked how many places we would actually have problems with that? I doubt it’s that many. A few? * QDataStream Interestingly enough, QDataStream is defined in terms of qintXX types (and it's missing long), QTextStream in terms of native datatypes (and has them all). * QString/QByteArray 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] Is qsizetype *documented* to be ptrdiff_t?
On 03/09/2020 06:08, Thiago Macieira wrote: Because qsizetype is the same type as qint64, which is the same type as qlonglong (which exists for historical reasons, because older VC++ didn't support "long long"). I'm very sorry, I'm lost now -- are you using as a postulate "on 64 bit systems"? I would've expected qsizetype to be 32 bits (on 32 bit systems)... But while qint64 should not change / still be the same type of qlonglong, why qsizetype has to be the same type qint64 and cannot be a different type (say, ptrdiff_t)? I don't have a problem changing the actual type those are aliases of. But I do have a problem making them different types. A lot of code assumes that qint64 and qlonglong are the same type. While they're always the same size, having them be different types could result in warnings and problems with overload sets. For example, say I've added QRandomGenerator::bounded(qint64) and quint64. qint64 v = QRandomGenerator::system()->bounded(str.toLongLong()); Does this compile or not? Devil's advocate: next to "toLongLong", why there isn't also "toInt64"? Or why does bounded() take int64, not long long? Do we have a policy on which one to use where? This smells like we're making the situation worse by increasing the mix types in the APIs rather than streamlining. 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] Is qsizetype *documented* to be ptrdiff_t?
On 02/09/2020 16:49, Thiago Macieira wrote: Lars has asked for qsizetype to be defined as the same type (not just the same size) as ptrdiff_t. Effectively, this means defining qint64 as the same type as int64_t. Sounds easy, right? Please remember that qlonglong is the same type in Qt as qint64. That means on these platforms, qlonglong would then be "long", not "long long". This is also reflected in our API: QString::toLongLong and QVariant::toLongLong -- will they return long? Those types are probably also used in a lot of overload sets and could break existing code. Moreover, it could make maintaining Qt5 and Qt6 codebases working together cumbersome. I'm not completely opposed to changing this. But I am asking whether it's worth the trouble. I'm lacking some context here, why does the definition of qsizetype affect toLongLong? I would imagine that toLongLong functions deal with "long long" no matter what. Why does this prevent making qsizetype == ptrdiff_t? Tor Arne wrote: As a user of this API I was also stumped by not being able to just call printf with %z and a qsizetype, under the assumption that qsizetype’s purpose in life was to mask_away_ the differences of what a size was represented as. That is indeed why C99 added the "z" and "t" modifiers. But unfortunately we still support one pre-C99 runtime, so you can't use them in cross-platform code. We're proposing every now and then to drop compilers and platforms for much less, but we do bother with supporting a toolchain that still doesn't implement 20+ years old standards? What's the percentage of users of that one? For restricted scenarios (MSVC-only or Unix-only code), you can use those modifiers. And in MSVC-only scenarios, there will be no type mismatch either, in both 32- and 64-bit. On 64-bit Unix, the result will be correct too, since the types are the right size. The only thing is you may get a compiler warning that the types mismatched. We could disable -Wformat. That sounds evil. It catches real bugs (just caught https://codereview.qt-project.org/c/qt/qtbase/+/299726 ). 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] Important recent changes in QList/QString/QByteArray
On 02/09/2020 21:18, Andrei Golubev wrote: Also not sure whether it is an implementation detail or the behavior that should always be anticipated. People build performance sensitive code assuming the cost of certain operations -- like, assuming that erasing elements from a vector never reallocates it; and that the only operation that sheds capacity is squeeze(), everything else (incl. clear(), incl. resize(0)) keeps the capacity (*). We should stop backstabbing them... (*) Which of course opens an interesting discussion in case of these operations detach Thanks, -- 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] Important recent changes in QList
Il 02/09/20 16:34, NIkolai Marchenko ha scritto: Since we're apparently heading to QVector being an alias to QList as opposed to what was a previous proposed solution. Can someone please elaborate on what breakages we can expect to happen in the old code with this paradigm shift? It seems like there's *almost* been a huge break with erasing behaviour. What else to expect? Please, let's be accurate: * Q6Vector is a typedef to Q6List (*) * Q6List is actually a vector (akin to Q5Vector / std::vector), and _not_ Q5List * Q5List is gone from Qt 6. So, what is exactly the question? (*) of course this could've been swapped, but the powers to be (aka who does the work) decided to keep QList as the main class, used in APIs etc., and alias QVector to it instead. Thanks, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Important recent changes in QList/QString/QByteArray
Il 02/09/20 17:38, Andrei Golubev ha scritto: But yes, good job bringing this up. In Qt 6 code base we also do the shrinking in erase. So this already is not aligned with std::vector. Even if the capacity has been reserved by the user? Thanks, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Important recent changes in QList/QString/QByteArray
Il 02/09/20 10:04, Ville Voutilainen ha scritto: Interesting. I'm curious what sort of repacking happens on erase, and why it wasn't done in such a way that e.g. QVector is 4 pointers instead of 3, so that the element storage wouldn't necessarily be at the beginning of the allocated block; in that approach, a pop_front would merely bump the begin, and erase still wouldn't invalidate anything before the erased position. With this setup, one might be tempted to optimize erasure in the first half of the container by shifting elements towards the end (rather than from the end towards the beginning), as it would be cheaper. I guess that's what's happening here? Thanks, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Important recent changes in QList/QString/QByteArray
Il 02/09/20 15:32, Dmitriy Purgin ha scritto: As far as I remember, until recently, for years we were told in this mailing list to move away from QList and use QVector as default, because QList will be deprecated/removed in Qt 6 anyway. Search in this ML's archives. The short story: * QList became QVector, meaning it's got QVector behavior * To avoid changing a ton of code, QList is the type used in API and "list" suffix is kept in names 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 de-facto "the" behavor everyone is relying upon, due to Hyrum's law. I don't have the energy to fight this, but my question was same lines -- legalese / documentation: what's the guaranteed behavior? 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 function call, but QVector doesn't have that). 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 intended by OP. Rather, that calling a non-const function may repack/reallocate a QCC (*), causing invalidation of all references and iterators, even if the container was NOT shared in the first place. Did I misunderstand the problem? (*) Qt Contiguous Container Thanks, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 is also true for non-detaching, non-reallocating modifying operations. 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. Yes, I assume that in practice begin() would already invalidate, and end() wouldn't, so it would work, but I'm asking what's formal model now. Is there a way to know that the next non-const call is going to invalidate everything? Side question, does anyone see a problem with begin() / data() / etc. no longer be noexcept O(1) operations? Thanks, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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, TorArne commented it's ready for integration, misses +2 though. It did get several +2 in the past, but needs constant rebasing past conflicts in other changes. Just rebased it, again. * (ideally) Qt::SingleShotConnection https://codereview.qt-project.org/c/qt/qtbase/+/311098 Currently +1, with CI testrun failing Anyone up to review? :) The testrun seems unrelated -- but anyhow, could anyone please fix what's wrong with coin? Since a few days ago the build logs are missing from the public testresults website. Thanks, -- 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
[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 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 about it. I'd like to request an exception for a few patches of mine which have been around for a while now: * QIM::multiData * QKeyCombination + removal of operator+(QFlags, *) * (ideally) Qt::SingleShotConnection The first two have to go in 6.0. Thanks, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
Hi, Il 27/08/20 16:47, Thiago Macieira ha scritto: So, can someone take a look at what it would take to make the models use 64- bit and come up with a proper guide for how to maintain code that compiles and works on both Qt5 and Qt6? The latter is very important: if you can't easily maintain for both, we just add to users' pain. It might be as simple as a typedef added to QAbstractItemModel. Finger in the wind: it's going to be painful. int-based APIs are used - in virtuals in QAbstractItemModel (rowCount(), but also things like moveRows() which take int as parameter, so changing it is a straight API break) - in Q(Persistent)ModelIndex - in convenience subclasses like QStandardItemModel (and of course in the convenience views) - in selection handling - in the views' convenience handlers (e.g. QAbstractItemView::rowsInserted) Long story short, I don't see this happening without also some configure-time switch for a "qaimsizetype" or somesuch. 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 overhead is much worse. This isn't accurate; QListView (with the default delegate) doesn't cache data, and only fetches and shows what's visible in its viewport. So the actual consumption is pretty much constant no matter how big is the underlying model. 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
Il 25/08/20 21:05, André Pönitz ha scritto: why I wanted a configure time switch to choose the size of qsizetype). This doesn't really help if Qt comes with your distribution or even with the Qt installers. What I meant is that it would be a porting aid towards Qt 6, rather than a switch to support "forever". Qt 7 (or 6.N for a big enough value of N) would use a size_t-sized qsizetype exclusively. 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
Il 25/08/20 07:49, Thiago Macieira ha scritto: But how about models? This is an honest question. Does it make sense for tables and lists that big? Note that an item*view* has a purpose of being viewed, so how does one display such a huge list, tree or table? Just another thought -- models may not necessarily used directly with views but as data sources for other business logic parts of the application (including but not necessarily limited to proxy models). Given the underlying data sources are 64-bit capable, such models should be as well. 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] How to change the status of a review from WIP back to active?
On 24/08/2020 17:02, Marcel Krems wrote: I have two reviews which have been cherry-picked to 5.15 with a merge-conflict. I have resolved the conflicts and pushed new changesets, but the status is still "Work in Progress". How do I change the status back to "Active" or if I am not allowed to what does one usually do to get this resolved? Top right corner, triple dot / burger menu, mark as active (I think). HTH, -- 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] qsizetype and classes working with QStrings or QList
On 24/08/2020 11:17, Mathias Hasselmann wrote: Do you have examples showing verifiable evidence, or do you share a feeling? There has been quite a flurry of patches into Qt fixing the generated warnings (shortening 64-to-32, using "%d" in printf, and the like). I don't have a way to list them all, I guess this is as good as it gets: https://codereview.qt-project.org/q/message:qsizetype 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] qsizetype and classes working with QStrings or QList
On 23/08/2020 16:06, Marcel Krems wrote: If they keep using int there could be a lot of warnings like this one: warning: implicit conversion loses integer precision: 'qsizetype' (aka 'long long') to 'int' [-Wshorten-64-to-32] I'm afraid that these warnings will be all over the place anyhow. Just how much code has been written against int-based APIs? (For the record, that's why I wanted a configure time switch to choose the size of qsizetype). But anyhow: yes, as a consistency factor, as many APIs as possible should be ported to qsizetype. Could you please file a bug report? Thanks, -- 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] QProperty and library coding guide
Il 20/07/20 07:21, Thiago Macieira ha scritto: ASM is not a solution. There's at least one major compiler (MSVC) that doesn't allow any assembler. What do you mean, MSVC doesn't allow inline ASM? I'm not proposing that the ASM itself needs to be emitted by moc, moc could just call a function implemented (in ASM) somewhere in qobjectdefs.h or so... But see Ville's email. I think the pointer arithmetic is actually fine. Would be fine too with uchar*. I'm really not sure what part of that paper would make it fine? -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
Il 19/07/20 20:42, Thiago Macieira ha scritto:
In that sense, Peppe's suggestion of C++17 offsetof is better.
To clarify, I was proposing to do something like this:
Type Klass::_qt_property_api_propertyName::value() const
{
/*1*/ const size_t propertyMemberOffset =
reinterpret_cast(&(static_cast(nullptr)->propertyName));
/*2*/ const auto *thisPtr = reinterpret_cast(reinterpret_cast(this) - propertyMemberOffset);
return thisPtr->d_func()->property.value();
}
* change /*1*/ become offsetof(Klass, propertyName);
* change /*2*/ to use ASM. We know the ABI of the platforms we support
and we know how to calculate the correct pointer value, we just need to
stop C/C++ from reason about it and flagging it as possible UB. Yes,
it's a crude hack... :(
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: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
Il 19/07/20 12:51, Oswald Buddenhagen ha scritto: - the compiler becomes intentionally belligerent, in which case an override switch will be provided as well (if not instantly, then after the outcry that immediately follows) File under "surely no compiler will optimize away X!", for X in * unspecified pointer comparisons * signed integer over/underflows * data races (on bitfields) * volatile in lieu of proper atomic access * proving that a loop doesn't terminate, hence the loop is never entered, and applying dead code optimization to it * ... To do any of the above is not belligerent, AND you have no way to switch the above optimizations off. (Also, you don't want to.) In other words: this is playing with fire in the long term run, that's why I suggested to bypass the C++ abstract machine, rely on ABI and use ASM. 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
Il 19/07/20 12:51, Oswald Buddenhagen ha scritto: - the compiler somehow starts to actually make use of the freedom granted by the fact that QObject is not standard-layout (this, btw, is also the reason why peppe's suggestion to use offsetof doesn't fix UB). offsetof is conditionally-supported for non standard layout classes in C++17.: http://eel.is/c++draft/support.types.layout#1.sentence-2 I haven't found any note in GCC/Clang/MSVC docs saying that they won't support it in this case, hence it's supported. http://eel.is/c++draft/intro.compliance#:behavior,conditionally-supported 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
Il 18/07/20 12:08, Arno Rehn ha scritto:
Can't we just hide the QProperty behind a method call, like with an
ordinary getter method? E.g.
class Foo
{
// ...
QPropert () {
Q_D(Foo);
return d->bar;
}
};
struct FooPrivate {
QProperty bar;
};
Sure, property access then isn't as nice as with the struct wrapper,
because you have the method call in between, but at least it's not
undefined behavior and there's a lot less complexity when putting it
into the pimpl object.
I'm assuming that one of the goals is to make the new property syntax
invisible and identical for the users. Code like this
auto value = obj->property();
must still compile, and decltype(value) better be the actual property
type and not any proxy object (which are still second class citizens in
C++).
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: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
Il 17/07/20 19:55, Thiago Macieira ha scritto:
moc generates:
Type Klass::_qt_property_api_propertyName::value() const
{
const size_t propertyMemberOffset =
reinterpret_cast(&(static_cast(nullptr)->propertyName));
const auto *thisPtr = reinterpret_cast(
reinterpret_cast(this) - propertyMemberOffset);
return thisPtr->d_func()->property.value();
}
The first two lines of this function are UB.
It MUST be fixed.
The first line smells like offsetof, which we might be lucky enough to
use -- in C++17 it became conditionally supported whether it works on
non-standard layout classes (QObject), and apparently GCC/Clang/MSVC all
support it.
The second line smells 99.99% unfixable UB. Would using ASM be an
acceptable "fix"?
In the process, please also fix this code:
auto prop = object->propertyName;
return prop.value();
How? Just like QStringBuilder, there's no way to block a `const auto &`,
is there?
Thanks,
--
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: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
Il 17/07/20 19:36, Thiago Macieira ha scritto: So in your example QSctpSocket would still be 24 bytes, because the inheritance is not deep enough to make sizeof 32? Yes, with the IA-64 ABI, assuming we don't mandate [[no_unique_address]] of course. Still, is it worth breaking ABI for sparing 8 bytes every 8 subclasses? With MSVC, it's 56 bytes. Well, this can't be helped anyhow as MSVC doesn't support [[no_unique_address]], so the implementation is going to be the union, with the associated costs. Thanks, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
Il 17/07/20 17:30, Thiago Macieira ha scritto:
I will give a +2 for this patch, since I prefer it. That means adding
properties doesn't imply an extra 8 bytes per class in the hierarchy. Imagine
a user class hierarcy like QSctpSocket -> QTcpSocket -> QAbstractSocket ->
QIODevice -> QObject. If each class has properties, that adds 40 bytes to the
full size of QSctpSocket.
[Yes, I know Qt-based classes should just put their properties in the d
pointer, but users don't usually have d pointers]
Even with d pointers, how is that supposed to work? You still need the
dummy "property object" in the class where it's declared, right? That
would still add 1 byte to the class, although that can be folded into
the alignment.
What am I missing here?
class QObject {
QObjectPrivate *d_ptr;
public:
virtual ~QObject();
union {
P1 objectName;
P2 somethingElse;
};
};
/* alignof == 8, sizeof == 24
(8 vptr + 8 d_ptr + 1 union + 7 padding) */
class QWidget : public QObject /*, QPaintDevice, I know */
{
public:
union {
P3 visible;
P4 geometry;
};
};
/* alignof == 8, sizeof still 24
(23 for the base class + 1 union + 6 padding) */
So in your example QSctpSocket would still be 24 bytes, because the
inheritance is not deep enough to make sizeof 32?
Thanks,
--
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: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
Il 17/07/20 11:36, Lars Knoll ha scritto:
And it’s cleaner, because using the union trick, we do access several members
of the union at the same time. It works on all compilers but I’m not 100%
convinced it’s fully defined behavior according to C++, even if the members
don’t have data.
To me, it's mostly the pointer arithmetic being sketchy (although
probably legal).
I don't see a particular problem with the union trick -- given N empty
classes
class Ex {};
And then the union
union U { E1 e1; E2 e2; ~~~ EN en; };
Then:
1) All of Ex and therefore U are standard layout classes [class.prop]
2) Therefore, the address of U is the same address as E1 [class.mem§26]
3) All non static data members of U have the same address [class.union]
It follows that U and all of its inner EN subobjects have the same
address, so you can apply the same offset to all of them reach the
QObject/gadget that contains U as subobject.
And why wouldn’t we do it, if the compilers support it?
Because it breaks ABI, and only relatively recent GCC versions have
support for the attribute... or does GCC have a nonstandard one?
Thanks,
--
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: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
Il 17/07/20 14:09, Ulf Hermann ha scritto:
QAction *action = ~~~;
auto prop = action->text;
This already gives you the string. You cannot retrieve the property
itself. You can alternatively do action->text() or action->text.value().
They all do the same thing.
Uhm... sorry, no, this doesn't really compute for me. Ignore the copy
semantics for a second (use const auto &, if necessary), what's
decltype(prop)? If it's QString, then you can't write .value() after it.
The member to access in the private object is hardcoded in the generated
implementation of value(). The public object to pick the private object
from is retrieved by offset from the address of the property. moc
generates code like this:
qreal QQmlComponent::_qt_property_api_progress::value() const
{
const size_t propertyMemberOffset =
reinterpret_cast(&(static_cast(nullptr)->progress));
const auto *thisPtr = reinterpret_cast(reinterpret_cast(this) - propertyMemberOffset);
return thisPtr->QQmlComponent::d_func()->progress.value();
}
I see where you're coming from. If the address doesn't exist, this
shouldn't be possible. However, no_unique_address does not mean that the
object has no address. It just means that it can share the same address
with other objects.
No, actually this makes perfect sense, but was contradicted before:
We are not casting these structs to or from anything though, do we?
So yes, you're casting them to perform pointer arithmetic and figure out
the address of the object to get the property from.
Thanks,
--
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: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
Il 16/07/20 17:40, Volker Hilsheimer ha scritto: The struct has no data itself, so ideally would be of size zero. I'm missing some piece of the puzzle: if you take action->text, and text is a zero-size struct, how does the operator() applied to it figure out which action needs to read the text property from? E.g. like so: QAction *action = ~~~; auto prop = action->text; QString text = prop(); Thanks, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
Il 17/07/20 11:05, Lars Knoll ha scritto: No, we should just static_assert for [[no_unique_address]] being available on the platforms where we expect it. That is, anywhere but on certain MSVCs. Some older embedded toolchains don’t have the flag neither. If we make it a configure feature, we open the door to BIC problems as we might accidentally turn it off in some builds. We should simply add a static assert that the Qt and the applications build mode are compatible. But what would be the advantage of switching from the union to the attribute? Saving 1 byte per class? Thanks, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
Il 16/07/20 12:43, Volker Hilsheimer ha scritto: For pre-C++20 (where it’s possible to have zero-size structs), and for compilers that don’t respect the [[no_unqiue_address]] attribute, all these struct-instances are put into a union. In that case, a class using QProperty will be larger (by the same amount no matter the number of properties) than the same class in Qt 5. With C+++ 20 and compilers that do respect [[no_unique_address]], the size and layout of these classes will be the same. I'm not fully understanding this last part -- does changing compiler break ABI, because the implementation of properties change (from an union to [[no_unique_address]] members)? Thanks, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
Il 16/07/20 12:43, Volker Hilsheimer ha scritto: For pre-C++20 (where it’s possible to have zero-size structs), and for compilers that don’t respect the [[no_unqiue_address]] attribute, all these struct-instances are put into a union. In that case, a class using QProperty will be larger (by the same amount no matter the number of properties) than the same class in Qt 5. With C+++ 20 and compilers that do respect [[no_unique_address]], the size and layout of these classes will be the same. Could anyone please illustrate with some code snippets how to achieve this, in practice, in a number of use cases? E.g. client code (non pimpled QObject subclass), (Qt) library code (pimpled QObject subclass), etc.; gadgets (does QProperty work there?); with and without other Q_PROPERTY/QProperty already present, etc. Thanks, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
Il 21/06/20 13:22, Lars Knoll ha scritto: We are making use of dynamic_cast and typeid in Qt nowadays, so I guess it’s high time we adjust the wiki. In the light of this: has anyone thought of deprecating in Qt 6 the ad-hoc casting functions like qgraphicsitem_cast, qstyleoption_cast and so on? (*NOT* qobject_cast) 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
Il 20/06/20 22:45, Thiago Macieira ha scritto: On Saturday, 20 June 2020 11:31:25 PDT Alberto Mardegan wrote: I think I missed an announcement about Qt applications having to use RTTI; on the opposite, I thought that the whole point of QMetaObject was not to require RTTI support; has this changed? As you can see from the commit, no provision was made for no-RTTI builds. I don't think they've ben allowed since 5.0. The Qt coding policy document still says that no RTTI facilities are allowed within Qt: https://wiki.qt.io/Coding_Conventions (Unchanged since 2015; before, I'm sure that document was somewhere else, with the same contents regarding this matter.) Where/when was such a change of policy decided? Thanks, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
Il 20/06/20 21:31, Alberto Mardegan ha scritto: Sorry, my wording was imprecise: we want to know if q is a*proper* subclass of QProcess (that is, a derived class). Note that inherits() / className() will not work as intended if the subclass does not use Q_OBJECT. Only typeid() will tell you the truth in that case. If you don't care about this use case, then ignore this issue :) HTH, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecating Q_STATIC_ASSERT_X and Q_STATIC_ASSERT
Il 11/06/20 11:11, Edward Welbourne ha scritto: That then leaves the question of whether we deprecate in Qt 6 or remove these macros. I shall leave Marc, who I understand as wanting the latter option, to make the case for it, lest I misrepresent that case. I fear the macros are going to be needed anyhow to support pre-C11 compilers. Qt itself can stop using them in C++ code (switching over static_assert). And I'd say that C++ mode we can assume static_assert presence everywhere, although the compiler detection will still be needed for C. Whether the macros should be documented or not: I keep asking, are they supposed to be public API? My answer is more towards a "no", but given we're keeping them around anyhow for C, I'd say to keep them working also for C++. Maybe we can use some trick to raise a warning for C++ code, but the maintenance burden for the C++ version is going to be 0. A data point: KDE has (only) ~30 hits of Q_STATIC_ASSERT. 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QMetaMethod in Qt 6
On 5/28/20 8:21 PM, Matthew Woehlke wrote: if a .cpp file has a #include "myclass.moc" type statement, that .cpp file has to be processed by moc Huh?*Why*? A direct use case of this is to support having Q_OBJECT classes defined in a .cpp file. That requires moc to parse foo.cpp file and produce foo.moc. The question is, does this happen unconditionally when a #include "foo.moc" appears a .cpp, even if that .cpp is not using Q_OBJECT & friends? Why would it be necessary in this case? 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] matrix math help needed - https://bugreports.qt.io/browse/QTBUG-84441
Il 28/05/20 16:18, Matthew Woehlke ha scritto: While that may be true, changing it now is going to break*every* user that uses these methods to generate compound transformations... and it'll be a silent break. I would be*very* surprised if that doesn't generate more bug reports. I 100% agree, no behavioral changes (clarifications in the docs are welcome) can be made at this point. Thanks, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] matrix math help needed - https://bugreports.qt.io/browse/QTBUG-84441
On 5/27/20 3:58 PM, Matthew Woehlke wrote: *Nothing* there clearly states, at least to my reading, whether the "new" transform happens*before* or*after* any existing transforms that the QTransform is already doing. IMO, changing this to clarify that would help significantly. Sure, augmenting the docs would help. But the whole point of the API is for its usage to be straightforward. If you do QTransform t; t.translate(); t.rotate(); t.scale(); auto result = t.map(foo); the "obvious" meaning should be that foo is getting first translated, then rotated, then scaled; not the other way around. If this is achieved by pre or postmultiplication of (transposed) matrices matters only if you're into Algebra™ -- i.e. poking into the actual matrix, or if you're combining two transforms by means of operator*. Otherwise, it is not interesting at all in 99% of the cases, where you'd just set the transform on a painter or an item similar. If you really want to use the "low levels", please also note that operator* is helping you: QTransform t1, t2; QTransform t = t1 * t2; // ok... auto result = foo * t; // can only premultiply! // operator*(t, foo) does not exist So you've built foo * t1 * t2, with t1 applied first. (This in turn should reveal how QTransform works internally.) 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] QUtf8String{, View}
Il 25/05/20 17:40, Thiago Macieira ha scritto: On Monday, 25 May 2020 04:37:26 PDT Edward Welbourne wrote: The "comparisons" heading might stretch as far as using a UTF-8 key to do a look-up in a QString-keyed hash, Using UTF-8 data to look up in a QString-keyed hash will require conversion to UTF-16 to calculate the hash. It can't be calculated on-the-fly. Being a bit creative, one could use an unordered_map, and with a custom transparent hasher that hashes the (first N) code points of the key... (Requires C++20) 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Drop MSVC 2015 in Qt 5.15?
On 5/25/20 8:51 AM, Tony Sarajärvi wrote: Or are you having new features coming in 5.15.1+ that would require additional coding to make it MSVC 2015 compatible? I strongly hope that there are *no* new features in patch releases. The question is mostly whether you want to support MSVC 2015 in the next three years, or drop it in the middle of 5.15's lifetime. The direct impact is on the ability of cherry picking patches developed against Qt 6. 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] QUtf8String{, View}
Il 23/05/20 03:06, Thiago Macieira ha scritto:
As we're reviewing the changes Lars is making to get rid of QStringRef, Lars,
Marc and I came to the conclusion that QUtf8StringView is required for Qt 6.0.
That's because some methods that previously returned QStringRef now return
QStringView and to retain compatibility with:
if (xml.attribute("foo") == "bar")
where QXmlStreamReader::attribute() returns QStringView, we really need to
capture that "bar" as a UTF-8 string and we ought to have optimised UTF-16 to
UTF-8 comparisons. So we're working on it.
To elaborate on this: does operator==(QStringView, char*) already exist
(maybe under QT_NO_CAST...)? If yes, isn't that char* already assumed to
be UTF-8? Do you want a QUtf8StringView to cleanly compile also under
QT_NO_CAST_FROM_ASCII (and obviously use UTF-8, not Latin1), to reap
compile-time strlen, etc?
Thanks,
--
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: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Qt Multimedia as Add-on in Qt 6
On 5/22/20 7:43 PM, Jason H wrote: I guess to some degree it depends on how you define "essential". The definition is: "Qt Essentials define the foundation of Qt on all platforms. They are available on all supported development platforms and on the tested target platforms." This summarizes two distinct requirements: 1) a technical requirement: the module must work on all platforms. 2) a maintenance requirement: the module maintainers must ensure it will work on all platforms throughout Qt 6.x lifetime (and if it doesn't, on ANY platform, it becomes a release blocker). QtMM may satisfy 1) (at the moment, cf. making it work on RTOS or so) but you can't argue with the maintainer about 2). On the other hand: "addon" does not mean "deprecated" or "unsupported" or any of the sorts. Qt3D, QtDbus, QtWebEngine, QtImageFormats and many others are "addon" modules and they are fully supported. 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] Qt Multimedia as Add-on in Qt 6
Hi,
Il 21/05/20 11:38, Val Doroshchuk ha scritto:
The license is not changed, plans just to not ship QtMultimedia with Qt
essentials,
can be installed separately. Possibly we also support only a limited set
of platforms.
Qt Essentials must work on every platform, according to the definition
of essentials.
While of course it's up to each module maintainer to decide on its
status (and thus, if QtMM doesn't qualify for "Essentials" any more, can
become an "Addon"), I'm left wondering why does this imply being moved
to the Marketplace, out of Qt itself?
* Is this part of a broader plan, aiming at streamlining the Qt offer to
just mean Essentials, while the Addons get moved to the marketplace?
("Qt offer" is of course inaccurate, given the many offers available,
but you get my drift...).
* If so, are all the practical issues for such addons sorted out? First
few things that come to mind:
1) Version numbering scheme, release schedule
2) CI testing / platform coverage
3) Compatibility promise (own API/ABI stability, which Qt versions it
works with, etc.)
4) Where to put the docs, release notes, etc.
* What about the KDE/Qt agreement? Are the list of Essential and Addon
modules being re-evaluated there as well? QtMM is not really at liberty
of changing license because it's an "Essential" (in the agreement).
Thanks,
--
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: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QUtf8String{, View}
On 5/16/20 6:16 PM, Thiago Macieira wrote:
That opens a philosophical question. In:
QString s = u"a a\u0301"; // U+0301 COMBINING ACUTE ACCENT
s.replace('a', 'b');
Should we now have a b with accent? (b́)
It's not philosophical at all, it's a defining question: at which level
does QString operate? It does not operate at the EGC level, it operates
at the UTF-16 level. (Proof: s.size() above is 4). Hence, the replace()
above is merely replacing 0x0061 with 0x0062 in the char16_t-like storage.
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] QUtf8String{, View}
Il 16/05/20 17:52, Arnaud Clère ha scritto: Regarding the relevance of a QUtf8String, I feel like it would not be so useful unless it allows to view its content as QChar instead of char (or char8_t) since handling multibyte characters is so error prone. At least a QChar handles most unicode characters as single entities... => QStringIterator. Cheers, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QString and related changes for Qt 6
Il 13/05/20 16:44, Matthew Woehlke ha scritto:
Note that adding the QString(char16_t*) constructor
Pedantic, but surely you meant `char16_t const*`.
Hey, you can't nitpick here ...
This can be solved with a third overload:
template
void foo(char16_t ()[N]) { foo(QStringView{s, N}); }
... and then do the same mistake in the same email >:-)
--
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: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QString and related changes for Qt 6
On 5/12/20 6:12 PM, Иван Комиссаров wrote: So the question is - is it possible to allow to construct QString from unicode literal? "Not yet", but adding a constructor from char16_t to QString makes sense. This creates a problem down the line: today you have a f(QString) and you call it with f(u"whatever"). Then, later on, you realize that QString is not needed and QStringView suffices. (This is the case all over existing Qt code.) What do you do? Adding a QStringView overload will make calls ambiguous, removing the QString one will be an ABI break. We need an established solution for these cases as they'll pop up during the Qt 6 lifetime. Note that adding the QString(char16_t*) constructor introduces this ambiguity for the functions that are already overloaded on QString+QStringView (and thus today are using QStringView). Thanks, -- 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] QString and related changes for Qt 6
On 5/12/20 12:20 PM, Иван Комиссаров wrote:
* Exceptions can be done where significant performance gains can be
demonstrated and the API will by design not require a copy of the data (e.g.
XML writer, stream writers, date time handling)
Let me disagree here. The decision should be taken on the fact if the object
takes ownership of the string (and thus QString is used) or it only «looks»
into it.
I agree. This however leaves us with questions regarding the API. E.g.:
class Attribute {
public:
// OK: takes ownership
void addAttribute(const QString , const QString );
// does not take ownership
bool hasAttribute(QStringView key) const;
};
Is it OK that you can call addAttribute("foo", "bar") but not
hasAttribute("foo")? (And similar)
Thanks,
--
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] connection timeout to codereview.qt-project.org:22
Hi, Il 07/05/20 23:11, Flaviu Tamas ha scritto: $ git push gerrit HEAD:refs/for/5.15.0 ssh: connect to host codereview.qt-project.org port 22: Connection timed out fatal: Could not read from remote repository. The right port is 29418. See also https://wiki.qt.io/Setting_up_Gerrit#Local_Setup HTH, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [SPAM] How bad QList really is
Il 28/04/20 21:45, Matthew Woehlke ha scritto: * QList gets adapted so that its internal array allocates 3 * sizeof(void*) per element, so that e.g. Q6StringList won't require a per-item allocation. This would then also avoid allocations for other datatypes, e.g. QStringView, QImage, maybe QVariant and QColor; but of course waste a ton of space for the ones which remain small (most of Qt implicitly shared datatypes). Uh... can't it allocate sizeof(T) if T meets some criteria? IOW, I don't see the second case penalizing smaller types unless the implementation is poorly done. This way of working is the *key* of QList design. QList is always a vector of void* (so it's nice for Qt pimpled types). This allows to type erase the entire management of the vector (it's always a vector of void*), reducing the amount of template code that needs to be instantiated. The only type specific operations are setting/retrieving/deleting a value in that vector, thus giving us the rule: - if the type is small and relocatable, just put it in the vector - otherwise, heap allocate and put the pointer in the vector There are no exceptions (which is why e.g. Q5List on 32 bits is wasteful), again by design. And, because noone is volunteering to do the work while QVector is already there... 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [SPAM] How bad QList really is
Il 28/04/20 11:16, Kevin Kofler ha scritto: * or the SSO gets reverted. It's not SSO. Is there any actual evidence that it is a win in practice? Yes. But it's not SSO. And on what hardware? Enough to justify the adoption in all std::string implementations and in 3rd party ones as well (e.g. Folly). It is very hardware-dependent whether copying several bytes is faster than incrementing one atomic. That may well be the case on today's hardware, but what about tomorrow's? Even more. And what about older hardware that is still in use? Right, let's establish the foundations for the Qt 6 lifetime (2020-2035) by looking at 2002 hardware. The rule of thumb should be that copying less is better than copying more. But: is copying less AND allocating better than just copying more? The confirmation bias comes from the fact that Qt datatypes are designed to work nicely with QList; this for at least two good reasons: a) Qt value types are normally pimpled (because of refcounting, or ABI stability) so they fit exactly in QList's array slots, but user-defined types aren't necessarily pimpled. Thus the bet: they're almost always the wrong size for QList. b) We've spent an awful amount of time reviewing Qt's source code and tagging down every value type as movable (where it made sense). And I'd like to extend a big thank you to Sérgio for clazy, Marc for tirelessly fixing the code, Thiago for giving us relocatable types before Qt 6 in QVector-but-not-QList-as-that's-BIC. Users simply forget the dreaded typeinfo macro and so, for their types, QList is always in array-of-pointers mode no matter the size of the datatype. I use implicitly-shared types and Q_MOVABLE_TYPE annotations in my code. Good. While we're at empirical evidence, do you want evidence of the contrary? Endless other users don't. Qt examples contain several instances of QList with Foo untagged and too big to fit anyhow. These can also usually be added later when needed. User code is not bound by as strict binary compatibility rules as Qt itself. Can be != will be. Those examples have been around for a decade. In conclusion, if QList is a good choice for Qt's own types, and even if we then expose it at the API level as the Qt container of choice, its only advantage then over QVector is going to be prepending? How often is that a use case to justify the semantic burden of this extra container? The prepending optimization alone is a necessary feature. Replacing QList with an unmodified QVector, without that prepending optimization, is entirely unacceptable. And the evidence for this need is? This cannot be claimed as a closed result: for insertion, it's ignoring the cost of the individual allocation of the newly inserted item, that needs to be traded off the moving of more bytes in memory. That is highly dependent on the hardware, the operating system, and the malloc implementation (where there is more than one for the operating system). So the results you obtain will depend on what you run the benchmark on. That's why I didn't provide numbers, but still pointed out that the result, alone, is wrong. -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [SPAM] How bad QList really is
On 4/25/20 4:49 PM, André Pönitz wrote: Spam detection software, running on the system "mx.qt-project.org", has identified this incoming email as possible spam. The original [*SIGHS*] We all know the story that began with "We knew for a long time that QList is not a good default container, despite what the documentation claims. The problem boils down to the fact that for a lot of types T, QList is needlessly inefficient by allocating elements on the heap and storing pointers to them instead of storing the elements in-place, like e.g. QVector does. Sometimes, for large and complex types, that might be exactly what you want, but a conservative estimate would put that chance at less than 5%." [1] I was curious how this "conservative" estimate of "less than 5%" manifests in real QList object instances in a real world example. My random picks of real world examples usually end up with "Loading the Qt Creator project in Qt Creator itself", and "statistics" is something I make up myself, in this case it is looking at QList objects at destruction time, and sorting them a bit according to size of the items in the list, number of items still present at that time etc. Besides being simple to do it's rather close to the typical use I see, where containers are filled up, accessed/used a few times and destroyed without much intermediate size changes. Here is what I get: * total QList objects created :51.631.363 - destructors that only bump ref :38.015.673 73.6% - destructors that actually dealloc :13.615.690 26.4% The 13.615.690 instances with actual deallocations ordered by the size of the item type: size occurences 4 1.656# 0.01 % with internal padding 8 13.424.228 # 98.59 % objects with ideal size, 12 3\ 1674.979 | 2460.560 | 28 126 | 3222.358 | 40 2.054 | 4818.786 | 5671 > # 1.40 % with indirection 64 3 | 7246 | 80 3.484 | 96 1 | 1127.264 | 128 52 | 1842 | 2112 17/ From the 8-byte objects we have 13.420.883 stored directly # 99.975 % of cases 3.345 stored indirectly# 0.025 % i.e. in 98.57% of all cases, QList objects behave optimally. Before we enter confirmation bias here: could you also offer a breakdown of the actual types involved? Basically, there's some important things to discuss here: 1) First and foremost, in Qt 6 QString, QByteArray, QVector, are bigger than a pointer (3 times a pointer size). So, in Qt 6: * either QList stays unchanged, and now we heap allocate each element for those cases too (thus it's necessary to know how the above statistics change); or * QList gets adapted so that its internal array allocates 3 * sizeof(void*) per element, so that e.g. Q6StringList won't require a per-item allocation. This would then also avoid allocations for other datatypes, e.g. QStringView, QImage, maybe QVariant and QColor; but of course waste a ton of space for the ones which remain small (most of Qt implicitly shared datatypes). 2) Please re-run the count also for the QVector instances in Creator. Under the "typical use" defined above, they could be converted to QLists, couldn't they? How much would the totals change? 3) How many datatypes are defined by Creator (so they could be considered "user defined", for the purposes of this exercise; although I believe Creator also employs pimpl quite aggressively to keep BC, or am I wrong here?), and how many are coming from Qt? The confirmation bias comes from the fact that Qt datatypes are designed to work nicely with QList; this for at least two good reasons: a) Qt value types are normally pimpled (because of refcounting, or ABI stability) so they fit exactly in QList's array slots, but user-defined types aren't necessarily pimpled. Thus the bet: they're almost always the wrong size for QList. b) We've spent an awful amount of time reviewing Qt's source code and tagging down every value type as movable (where it made sense). And I'd like to extend a big thank you to Sérgio for clazy, Marc for tirelessly fixing the code, Thiago for giving us relocatable types before Qt 6 in QVector-but-not-QList-as-that's-BIC. Users simply forget the dreaded typeinfo macro and so, for their types, QList is always in array-of-pointers mode no matter the size of the datatype. This is the area I fundamentally consider the "original sin" more than anything else: QList can be a terrible default choice for end users and their datatypes, while it's possibly still a good
Re: [Development] Proposal: Deprecate QVector in Qt 6
On 4/24/20 9:03 PM, Jason H wrote:
In fact, it is-a QList. What's the problem here with its naming?
Because I can't QSringList{"me", "you"}.join() with a QList.
I didn't say that it's a typedef for QList, but is-a -- it
inherits, precisely to provide that kind of convenience.
Thinking outsize of the box...
It seems that all this is cause d by someone wanting to store a pointer to an
item in QVector, which may be reallocted and therfore have moved.
All this => what's this?
It seem then that the only thing to do is to use a traditional QList, or return
only some kind of ref which will be a stable reference to the item.
QStableRef r9 = vector[9];
vector.resize()
// r9 is updated during resize() and still points to that it was meant to.
It's not good practice to store a ref to something that can be realloated. I don't
know how you can prevent people from doing that with offering T& operator[](int
i);
QList today offers exactly that. In array-of-pointers-mode it also
offers stability of references.
Thanks,
--
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] Proposal: Deprecate QVector in Qt 6
On 4/24/20 8:57 AM, Joerg Bornemann wrote:
Alternatively, proposal 3 (aka "do almost nothing"):
template class QVector { implementation }
template using QList = QVector;
No deprecation of QVector.
No replacement of QList with QVector in our API.
Rationale: QList is our default sequential container, and in Qt6 we just
change its implementation.
Could you please argument a bit more? In particular:
* Is it OK to live with a mixup of containers in the APIs? What's the
downside in terms of consistency, teachability, learning, etc.?
* If I'm adding a new function, what would the coding guideline be,
take/return QList or QVector? Why?
* What's the reason against the replacement? It's not worth it in terms
of manpower, or another guideline?
Thanks,
--
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] Proposal: Deprecate QVector in Qt 6
On 4/24/20 12:36 PM, Edward Welbourne wrote: Giuseppe D'Angelo (24 April 2020 10:19) asked Which "one year release approach" are we talking about here? That would be Vitaly's proposal to have major releases yearly. I must be missing something: how would that help, regarding the problem at hand? In other words, how does such a decision influence the solution of the problem? Thanks, -- 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] Proposal: Deprecate QVector in Qt 6
On 4/23/20 11:10 PM, Vitaly Fanaskov wrote: How often do you think we can play this game until people look for something they consider more stable? Moving to one year release approach doesn't equal to make Qt less stable. Which "one year release approach" are we talking about here? Thanks, -- 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] Proposal: Deprecate QVector in Qt 6
On 4/23/20 6:54 PM, Manuel Bergler wrote: This is a documentation bug or a Creator bug. You're supposed to land on this anchor:https://doc.qt.io/qt-5/qvariant.html#QVariantList-typedef Technically this is the correct place to land on, but it isn't helpful. Just like Julius, if I have a container most of the time I care about the API of the container, not about the API of the value_type. So I expect to see the API for that container when I open the documentation, but when intuitively scrolling up to the list of member functions it sometimes takes several seconds for me to realize that I landed on the QVariant page instead. If it were written as QList I could choose to either open the documentation for QVariant or for QList. This is still a suggestion for Qt Creator, though. Note that the link above contains links to both QList and QVariant. And I have to remember if QStringList is the same as as QList, or if it's actually a different container with a different API. In fact, it is-a QList. What's the problem here with its naming? The issue is that Qt itself is not consistent with the naming. QStringList is just an alias for QList, but e.g. QDomNodeList (https://doc.qt.io/qt-5/qdomnodelist.html) isn't. So unless you've frequently used the particular type you always have to look it up. If it were spelled as QList it'd be obvious. This is: 1) an indication that by using "List" in the type name we don't actually mean QList, but we mean "sequence of"; and/or 2) an API mistake. Thanks, -- 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] Proposal: Deprecate QVector in Qt 6
On 4/23/20 5:04 PM, Julius Bullinger wrote: Another suggestion: Get rid if the aliases; use the fully-qualified types instead. I'm always irritated if I open the documentation of QVariantList from within Qt Creator, and land on the QVariant docu instead. I'm interested in the features of the container, not the contained type. This is a documentation bug or a Creator bug. You're supposed to land on this anchor: https://doc.qt.io/qt-5/qvariant.html#QVariantList-typedef And I have to remember if QStringList is the same as as QList, or if it's actually a different container with a different API. In fact, it is-a QList. What's the problem here with its naming? Thanks, -- 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] Proposal: Deprecate QVector in Qt 6
On 4/23/20 1:20 PM, Edward Welbourne wrote: So how much harm does it really cause, to keep both names; and use whichever feels like the more natural description of the value one is returning ? I missing the bigger picture about this thread. What are we trying to assess / solve? == Source compatibility in the presence of QList = QVector (only relevant for porting code from Qt 5 to 6)? == There are some known breakages [1]. But the example quoted before, QList fun(); will still work whether the client code uses QList or QVector to store the result. That's why I was asking what that was about. Similarly, QVector fun(); will also allow QList l = fun(); Can this cause source incompatibilities? How? How would the proposed QVector = QList change things instead? == API maintenance if QList = QVector: do we mass s/QList/QVector/g in our public APIs? == I'd be in strong favour of it; it favours consistency and one single message. Please: let's not open the debate about whether it's a good idea to have functions that return containers when such containers are not part of the object representation (vs: those functions use output iterators, or become coroutines, etc., so I can choose the container I want). We have those functions around and we need a source compatible solution for them in 6.0. The problem I see with this is the sheer size of the task ahead. I'm not sure how much it can be automated. Has anyone tried? Even if some magic script fixes everything we may still need manual style touches. Does it need a C++ parser, or can it be a mass search? (And even if could build a clang script that does it for Qt itself, what about user code which won't compile at all under clang?) On the positive side, since we're talking about typedefs, this can be done incrementally, without any API/ABI compatibility concerns. If we went the other way around, i.e. QList is the "default" type, like proposed: doesn't the task stay fundamentally the same? == Naming of functions and types if QList = QVector == We have QStringList, QVariantList and friends, which are aliases / subclasses of QList and so on. Should they become QStringVector, QVariantVector; and the *List names stay, aliases for the *Vector names, mirroring QList and QVector themselves? I'd say yes, but this has another impact on the API maintenance (we should change all of our public APIs to use the *Vector types, for consistency). A broader question is: in the long run, do we want start deprecating all the *List names, and leave just the *Vector names? If yes, then certainly we have to do the replacements. As proposed in this thread, if we keep QList and make QVector the alias, then we would just leave these datatypes unchanged, and there would be no need of introducing the *Vector counterparts. Functions naming: how many public APIs have a "List" suffix, specifically returning a QList? (=> QTextCursor::insertList doesn't count.) First and foremost, we have a problem of coding guidelines, which demand simple pluralization of the entity returned, not "List" suffixing: * QObject::children, not childList * QObject::dynamicPropertyNames, not dynamicPropertyNameList * QSslSocket::sslErrors, not sslErrorList * QRegularExpressionMatch::capturedTexts, not capturedTextList * QSslConfiguration::supportedEllipticCurves, not supportedEllipticCurveVector (yes, this one returns a QVector) So the first "go to" solution is: rename the functions, so they follow the guideline (keep and deprecate the old name). Second, would it cause confusion for a function called getFooList() to return a QVector? Is "list" used as an abstraction of the return type (it doesn't return an object, but a sequence of them), or strictly in some sort of Hungarian notation to require that the type returned is a QList? (And I mean, specifically _spelled_ QList, even if it's an alias to QVector). I don't have a good answer here. == Terminology, "list" vs "vector"? == Debating whether "vector" is a good term for the respective container is only useful for mathematicians and linguists -- in other words, all aboard the bikeshedding train! But: *today*, in 2020, in C++, it represents a very specific and well-understood thing. Same for "list". They should cause no ambiguities. I cannot stress enough that we shouldn't and cannot possibly care about the names in other languages! (Otherwise, "list" in Python is heterogeneous, why isn't QList heterogeneous? Don't we care about developers coming from Python? Repeat for any other language out there.) The major problem in this department has to do with caring that something is actually a vector (contiguous in memory, etc.) rather than just a sequence implemented "somehow" (... as efficiently as possible, this is C++ after all). In this regard, QList is a bad term for representing a generic sequence (because "list" already has a meaning in C++). I'm
Re: [Development] Proposal: Deprecate QVector in Qt 6
On 4/23/20 10:55 AM, Simon Hausmann wrote: So take for example this function in QIconEngine: virtual QList availableSizes(QIcon::Mode mode = Icon::Normal, QIcon::State state = QIcon::Off) const; If we change that to QVector, we require our users to clutter their code base with #ifdefs. If we keep it with QList but use QVector in all non-virtual functions, then we create a less consistent API. Why do you say "we require"? What kind of user code would break? Thanks, -- 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] Can QImage format plugins require QGuiApplication?
On 4/14/20 11:30 AM, Allan Sandfeld Jensen wrote: > No, any GUI-related API requires QGuiApplication, and any widget-related > API QApplication. > In theory, but see https://codereview.qt-project.org/c/qt/qtbase/+/47846 I would stick to the documented contract, without any fancy ad-hoc workarounds that work today and may get broken tomorrow. Case in point, image plugins have the right of happily start loading fonts, accessing the clipboard, querying the screen DPI and whatnot. Any breakage caused by this because of a lack of a QGuiApplication instance is a bug in application code, not Qt. 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] Can QImage format plugins require QGuiApplication?
Hi, On 4/14/20 1:34 AM, Konstantin Tokarev wrote: The golden rule is that you're not allowed to touch any Qt API without creating a Q*Application object first, unless the documentation says otherwise. Question is whether Q_Core_Application should be sufficient for using and image format plugin, or QGuiApplication/QApplication is required. No, any GUI-related API requires QGuiApplication, and any widget-related API QApplication. 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] Can QImage format plugins require QGuiApplication?
Il 13/04/20 18:50, Kevin Kofler ha scritto: Today, a user on #fedora-kde ran across a crash which resulted from: * a GTK+/GNOME application (Jami) using (for some reason) QImage to load images, without a QGuiApplication or QApplication constructed, vs. * a QImage format plugin (QtPBFImagePlugin) using font APIs that require QGuiApplication and abort otherwise. Obviously, one or the other must be wrong. So, who is to blame? The golden rule is that you're not allowed to touch any Qt API without creating a Q*Application object first, unless the documentation says otherwise. HTH, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5.15 API review
Il 10/03/20 13:45, Jani Heikkinen ha scritto: We haven't been blocking Beta (n) lately because of ongoing API review. Earlier when there were only one beta we did that. After we started to deliver several beta releases we stopped to block betas because of not finalized API review. And I think that is correct way to do this; It is better to start publishing beta releases as soon as possible instead of waiting until API review is complete But then, what's the difference between the alpha releases and the beta releases? Thanks, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5.15 API review
Il 10/03/20 10:53, Jani Heikkinen ha scritto: It seems API review is still ongoing and many reviews are missing +2: But, out of curiosity, why was the beta published when API review was still ongoing? Thanks, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
Il 24/02/20 13:48, Mitch Curtis ha scritto: In that case, I share the same concerns as Andre in that it requires IDEs to have knowledge about Qt. I only use Creator, so it won't bother me, but it will affect others who are e.g. transitioning or are so used to another IDE that they'd never switch. Semi-related to this: Jira still doesn't know about QML as a highlighter syntax, 11 years later. :) Not to mention: code review, which doesn't highlight anything at all. 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Why isn't FocusScope a property on Item?
Hi,
Something that I've always wondered about (and hopefully whose reasons
have been lost in the Nokia times) is why FocusScope exists a dedicated
item, rather than simply being an ordinary property on Item?
Any custom QQuickItem subclass can be a FocusScope, it just needs to set
a flag on itself. Why is the flag something only toggable from C++,
rather than being a Q_PROPERTY?
The *entire* implementation of FocusScope is exactly what one may think:
QQuickFocusScope::QQuickFocusScope(QQuickItem *parent)
: QQuickItem(parent)
{
setFlag(ItemIsFocusScope);
}
What's the problem with this? It's just that one needing a focus scope
in QML needs to introduce a new element in the tree. That is *super*
annoying: it messes up sizing / anchoring, requires aliasing properties
from FocusScope's contents, and so on.
So, does anyone know the historical reasoning here, or any good reason
for not changing FocusScope just a normal property on Item?
(Note: I'm not opening the problem about whether a component/top level
item in a QML file isn't automatically a focus scope -- that would lead
to "interesting" complications of the language.)
Thanks,
--
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: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
Il 21/02/20 17:42, Thiago Macieira ha scritto: The first step would be for both qmake and cmake projects to warn if the project doesn't declare keywords or no_keywords. Allow that to stay for 2 or 3 years so projects do update to declare their choices. This can start right now, in 5.15. At some point after that, change the default. Like, for example, in Qt 7. A data point I'd like to have is how many "real world" projects are enforcing no_keywords, at the moment? Are we going to make life more awkward for everyone, with a marginal gain (stop polluting the preprocessor with lowercase macros), or _de facto_ any big project already disables the macros anyhow? 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
Il 21/02/20 13:59, Shawn Rutledge ha scritto: (Some people name every slot function starting with the word “slot” to make clear what it is.) So, literally any function they write, since _anything_ can be a slot? Or any function in a QObject subclass? (Not to mention that functions are supposed to describe what they do, not what they react to...) Sigh.. -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
Il 20/02/20 14:44, Kai Köhne ha scritto: As a counter proposal that (I hope) would get broader consensus, I suggest to just do this for 'emit': QTBUG-82379 . I don't think this is exactly a counter proposal for the plan or the scheduling posted by Marc, though. We're now bikeshedding about Q_EMIT vs [[qt::emit]] vs. qEmit or anything. Can we instead discuss about the plan instead? AFAIU it could be simplified as: * Qt 6.x ** Introduce opt-in ways to request lowercase keywords: -DQT_USE_KEYWORDS, CONFIG+=keywords, whatever. They do nothing. ** Default for user projects is still same as today (use lowercase). ** User projects get a deprecation warning unless they specify no_keywords and/or keywords. Specifying both keeps keywords. * Qt 6.[x..x+3] ** Qt turns on no_keywords for itself (all code, examples, docs). ** Nothing changes for end-user code. * Qt 6.(x+3) ** Default for user code becomes no_keywords. Am I reading the original proposal correctly? The (x+3) here means that there'll be at least one LTS in the middle where behavior won't change for end-user applications. 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
Il 21/02/20 09:23, Kai Köhne ha scritto: Another alternative is to actually use C++ attributes for this: [[qt::emit]] somethingChanged(); C++ attributes are required since C++11, and since C++17 the compiler is also required to just ignore one's it doesn't know [1]. Because it is part of the core language, It is also something every C++ IDE and tool does accept (and could even check for) ... This is a tad verbose, but agreeable IFF we also introduce [[qt:::slots]], [[qt::invokable]], [[qt::property()]], and so on -- in other words: if we have a _consistent_ set of keywords... Thanks, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
Il 21/02/20 12:49, Julien Cugnière ha scritto: Isn't that true of any function call though ? Any function could end up deleting this, or trigerring code in another thread, or anything. For example, a normal function call could end up emiting a signal, and as such, any function could be as dangerous as a signal. Not really: for functions you call explicitly, you know their preconditions and postconditions. printf is not going to delete this, and malloc is not going to reenter another function of your object while you're mutating the state risking to find garbage. The big difference with signal emission is that they don't generally impose anything at all (preconditions, implementation, postconditions) on the slots being connected, in the name of loose coupling. As someone reasoning on the code emitting the signal, the annotation that control is leaving and anything can happen at that point is a positive ε of valuable information. The other problem with emit, is that it's not required. So its absence doesn't mean a signal is not being emitted. Sure, but that's why Clazy is angry about emit missing in front of a signal call, or if someone puts emit in front of something that is not a signal. -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
Il 21/02/20 12:15, Ville Voutilainen ha scritto: without any annotation is not what we want. We'd miss vital information and reduce readability. Can you please explain what that vital information is? That control is leaving the "local" function, and *anything* can happen at that point. Including fun stuff, like finding "this" to be deleted (pgrep for QPointer.*this in QWidget code). It's an important annotation for a developer IMNSHO. 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
Il 13/02/20 10:57, Vitaly Fanaskov ha scritto: I think that moving Qt smart pointers to Qt5Compat module creates almost no hassle. For Qt users it should be a one line in the terminal to replace includes in their code bases (probably also prepend a namespace to classes' names, but I'm not sure if there is a namespace). In general, I'd say that this is another problem should be addressed separately. Feel free to kick off a new thread. Is there a QTBUG tracking this idea? It's not "so simple" because Qt smart pointers are being used in a couple of public APIs. -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
Il 03/02/20 23:55, André Pönitz ha scritto: On Mon, Feb 03, 2020 at 10:25:21PM +0100, Giuseppe D'Angelo wrote: Il 03/02/20 20:38, André Pönitz ha scritto: Directly affected are for instance functions operating on full containers in https://doc.qt.io/qt-5/qtalgorithms-obsolete.html Just to set the record straight, the main reason why qAlgorithm(begin, end) as well as qAlgorithm(container) have been deprecated altogether, rather than simply have their implementation replaced with std::algorithm() calls, was the fact it would've been source incompatible. I think I've never needed qAlgorithm(begin, end), but used quite a bit of qAlgorithm(container). For instance: qSort internally uses calls to qSwap and qLess. So what? It worked. Now it doesn't anymore. So changing qAlgorithm(container) implementation to call std::algorithm(container.begin(), container.end()) would have been a source incompatible change. (Side note: throughout the entire Qt 5 lifetime qAlgorithm(container) still 100% works -- it's deprecated, not removed.) In other words, in the Qt4->5 time, the choice was between one of these: A) Keep QtAlgorithms as-is between Qt 4 and Qt 5, leave them fully supported. B) Keep QtAlgorithms API as fully supported, but change the implementation under the hood to use std::algorithms. C) Deprecate QtAlgorithms API, leave them as-is for Qt 4 compatibility. Tell the users that they have Qt 5.x entire lifetime to migrate away. D) Something else: e.g. add the convenience wrappers back in some other namespace (after the port to std::algorithms, so with different semantics) etc.; no one has proposed or done so far. Amongst these choices, A) was deemed a poor one (NIH + Qt only having a handful of algorithms, not all, and C++ getting more and more + QtAlgorithms implementation being much worse in feature set and implementation -- read, performance). B) is a "hidden" source incompatible change (code would still compile but break at runtime). I cannot stress enough that the ultimate reason for the incompatibility is the decision of making the QtAlgorithms themselves non-Standard (I know that -no-stl was the ultimate reason behind this decision. Still, it's a fact.). The argument of diverging from upstream when reimplementing low-level facilities in Qt popped up a bunch of times in this thread: the algorithms prove the point that it's a bad idea, because it will bite you in the long run. So we went for C). Meaning that your code using qSort still works 100% fine (it's deprecated, not removed, and kept identical semantics). And also meaning that you'll have to spend "some" time to do a port. (Actually, coming Qt 6, we now have the qSwap name back, so we can do B) without worrying the SIC). Is it bad and will cause pain and frustration to downstreams? Unfortunately yes -- and I'm not having any joy at being the bearer of bad news. D) would have helped with the impact and AFAICT no one would be opposing such a thing. Was all of this done because "I don't need qAlgorithms' convenience so no one needs it"? Absolutely not! Should we had gone for B) instead? I say no, QUIP-6 says no, other people are feel to say yes. (Side note: this *will* fuel arguments against using Qt facilities, namely, "Qt regularly breaks them".) An user overloading or specializing them would have had their algorithms broken by the mere replacement towards std::sort (which instead uses an ADL-found swap() + std::swap, and std::less). And most user code breaks by a mere replacement of 0 by 1. What kind of argument is that? "Break existing code, since other code might potentially break when uses replace some function by something else"? No: it would break existing code without the user changing their code at all. Qt 4: qSort(foo) (uses qLess) Qt 5: qSort(foo) (uses std::less) Users don't change their code; code compiles just as before; behavior and thus semantics of the call change, possibly breaking at runtime. That's a source incompatible change, of the worst kind. So, for the record, if you want to point the finger against the deprecation/removal of these algorithms, please point it against the decision of making the Qt 4 algorithms _diverge_ from upstream, then noticing that Qt cannot or shouldn't catch up with the significant improvements happening upstream, then realizing that a direct port isn't doable because of the diversion. I have already said that having different behavior from from upstream is a terrible idea in this very thread, and the algorithms example is an excellent one. There is not upstream 'sort(Container)' that this has possibly diverged from. Oh wait, in C++20 there is :-P More seriously: is this arguing for having qSort(container) still around with the Qt 4 implementation? Now, we may disagree on the extent of the incompatibility -- in the end, who would override qSwap, specialize qLess, and so on? Can't we just bite
Re: [Development] The future of smart pointers in Qt API
Il 04/02/20 00:49, André Pönitz ha scritto: I've asked "what's wrong with the C++ smart pointers" a dozen times and never received a satisfactory answer. Did you? I am - to some degree truly - afraid I didn't notice. [snip] I apologize, I should've asked more clearly: "what's wrong with the C++ smart pointers that demands re-implementations of them in Qt"? Your answer is on point regarding the usage of smart pointers in general (no matter who's providing the implementation); it's a starting point for a discussion relative to Daniel's proposal, I guess? Thanks, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
Il 03/02/20 17:56, Jason H ha scritto: As a result, the code of a Qt-using program should be readable by average developers not big into C++. But no one is imposing super-advanced C++ features on Qt users and Qt applications... Meanwhile, it also does not serve anyone to duplicate stl. I do not know where the threshold is for duplication (probably pretty high) but I would encourage the threshold to be low for augmentation. I've asked "what's wrong with the C++ smart pointers" a dozen times and never received a satisfactory answer. As a counter-example: I didn't complain at all about having a QFuture with a different feature set than std::future (cf. the other thread on this topic). Why is that? Because std::future lacks critical features (e.g. continuations); QFuture aims at filling that gap, and I'm super-fine with that. Do you see me complaining about QString vs u16string? 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
Il 03/02/20 20:38, André Pönitz ha scritto: Directly affected are for instance functions operating on full containers in https://doc.qt.io/qt-5/qtalgorithms-obsolete.html Just to set the record straight, the main reason why qAlgorithm(begin, end) as well as qAlgorithm(container) have been deprecated altogether, rather than simply have their implementation replaced with std::algorithm() calls, was the fact it would've been source incompatible. For instance: qSort internally uses calls to qSwap and qLess. An user overloading or specializing them would have had their algorithms broken by the mere replacement towards std::sort (which instead uses an ADL-found swap() + std::swap, and std::less). So, for the record, if you want to point the finger against the deprecation/removal of these algorithms, please point it against the decision of making the Qt 4 algorithms _diverge_ from upstream, then noticing that Qt cannot or shouldn't catch up with the significant improvements happening upstream, then realizing that a direct port isn't doable because of the diversion. I have already said that having different behavior from from upstream is a terrible idea in this very thread, and the algorithms example is an excellent one. Now, we may disagree on the extent of the incompatibility -- in the end, who would override qSwap, specialize qLess, and so on? Can't we just bite the bullet and break those rare usages rather than forcing everyone to port away? As the one who did the porting work, then I get the privilege to say: no, we can't; this is a gratuitous and very hidden source-incompatible change, and the promise of Qt 4->5 was to keep them at a minimum. (And, I don't like them.) So, keep using the deprecated qAlgorithms if you want, throughout the entire Qt 5.x lifetime, with the same Qt 4.x semantics; they still work just like before. _Port_ to the std:: equivalents at your earliest convenience (no, you cannot do a mere s/qAlgorithm/std::algorithm/ in the general case; it's a full port). Other people are free disagree with this. (For instance, in Qt 6 the decision (which I disagree with) was to introduce similar gratuitous and very hidden source-incompatible changes, e.g. with QList and QHash both breaking iterator stability. I am nowhere near those changes :-)) Indirectly, standard containers have no direct equivalent of .contains(), so advocating using std over Qt has a similar effect here. I've never proposed replacement of Qt containers in favour of Standard Containers, though. The times we discussed interoperability was for scenarios like "uses internally" (e.g. QHash implemented using std::unordered_map internally). That would've meant keeping the richer Qt container API (indexOf, contains, etc.) 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
Il 03/02/20 14:59, Vitaly Fanaskov ha scritto: If we're going for this logical fallacy, then let's up the ante: a unique pointer is just a shared pointer without copy semantics. Why not using shared pointers everywhere? Well, I hope it was rhetorical question, please, let me know if not. Yes, it was. The difference between shared pointer and unique pointer is fundamental. But there is no fundamental difference between unique pointer and scoped pointer. The both uniquely own a resources and resource lifetime is equal to smart pointer lifetime unless it explicitly prolonged. The only difference is a way how you can do that. In case of scoped pointer you can invoke method "take", in case of unique pointer you can also use move semantic. Looks like that scoped pointer is just yet another redundant entity. A scoped pointer shouldn't have a take() function (or anything similar). That's an API mistake: it enables the pointer to escape the smart pointer, which is exactly what the name says it can't happen. Let's see a bit further over there: * boost::scoped_ptr: no release() (*) * std::unique_ptr: release() * std::lock_guard / scoped_lock: no release() * std::unique_lock: release() (*) Argument by Authority: https://www.boost.org/doc/libs/1_72_0/libs/smart_ptr/doc/html/smart_ptr.html#scoped_ptr_frequently_asked_questions I do agree that the type is "redundant" because it's equivalent as a const unique_ptr (as said in the other email). But the premise of the of the argument was: "give me at least one example when I cannot replace scoped pointer with unique pointer without losing readability and maintainability". If we accept that fallacy, I can also replace any unique pointer usage with a shared pointer one. Introducing an alias should satisfy some people who used to use scoped pointer. An alias from what to what? I'm a bit lost now. std::unique_ptr ptr = ~~~; return ptr; For example. With a scoped pointer it's a bit harder to do that, but also possible, I think, for example: QScopedPointer ptr = ~~~; return QScopedPointer(ptr.take()); This, unfortunately, shouldn't be possible; it's an API mistake. I believe it was raised during the same discussion of making QScopedPointer movable, but we never actually fixed it. What? This is absurdly false -- the Standard Library is part of the C++ standard itself. Which doesn't mean that this is a part of the *programming language*. If you read carefully some parts of the standard, you can notice that, for example smart pointers or containers are not mandatory. For example: "This Clause describes components that C ++ programs may use to organize collections of information." The claim was: "STL is not a part of C++ language itself and cannot be considered as a default standard." The claim was false. It is a part of the programming language, and it it standardized, and any conforming implementation must ship it. The specification is called "International Standard ISO/IEC 14882:2017(E) – *Programming Language* C++" (emph mine) and it includes the standard library. Now parts of the standard library are optional in freestanding implementations. Which we don't care about anyhow. Qt since 5.0 requires the presence of a Standard Library. We worked around missing bits by not making them hard requirements, but the more we move forward in Qt 6, the more aggressive we'll be with these requirements on compiler vendors. Changing the interface in any way which are incompatible with the Standard counterparts is a _terrible_ idea. It kills the principle of least surprise; it makes such facilities incompatible with the STL counterparts, preventing interexchange of data and code; and come Qt (N+1), it will prevent a clean pass of s/QtFoo/std::foo/g over the codebase. It's not a big issue if we have Qt wrappers around std smart pointers. A standard smart pointer that is under the hood should be easily accessible. And I keep asking the details: what is not good enough in the standard smart pointers to justify a reimplementation in Qt? How does this trade off with the other points I've made? (Interoperability, maintenance, teachability, etc.) How do you integrate QSharedPointer with std::shared_ptr exactly? If QSharedPointer is just a wrapper around std::shared_pointer it should be easy. Adding one more constructor and an operator to the wrapper. Same set of questions here. 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
On 02/02/2020 22:45, André Pönitz wrote: This is a logical fallacy; "I don't need it, noone else does". But this is the argument the de-Qt-ers use when it comes to Qt convenience they don't need. Which Qt convenience in particular? I seem to be advocating against duplication "for the sake of it", not when there's strong arguments (e.g. convenience) for it. Cheers, -- 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] The future of smart pointers in Qt API
On 02/02/2020 21:26, Alberto Mardegan wrote: This is a logical fallacy; "I don't need it, noone else does". Yes, but it's a logical fallacy you yourself made up Excuse me? In my work experience, when I'm not allowed to use Qt and am restricted to the STL, all the times I had to use std::unique_ptr was to get the same behaviour as a QScopedPointer. -- 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] The future of smart pointers in Qt API
On 02/02/2020 17:34, Alberto Mardegan wrote: On 01/02/20 15:02, Giuseppe D'Angelo via Development wrote: Il 01/02/20 12:44, Alberto Mardegan ha scritto: On 01/02/20 02:46, Giuseppe D'Angelo via Development wrote: About QUniquePointer: what's the point of reinventing std::unique_ptr under a different name? A Qt-ish API! Example? A data() method :-) Upstream is settling on the convention of having data() on things that also have size(). Smart pointers lack the latter so they don't have the former. Is it questionable? Sure. In principle, data() on smart pointers may actually be added (in the sense that it would be 100% backwards compatible). Do you happen to have a proposal for it? Is this a difference so big and important to justify diverging from it? I am very unconvinced. It's not clear to me what you mean by "alias"; if you mean a subclass, then I'd be against it, because there's a (very small indeed) risk that in the future the STL adds some methods that might conflict with ours, or would not be Qtish enough. I mean a type alias: using QUniquePointer = std::unique_ptr; It still bring the risk of the STL adding some weirdly named methods (such as empty()) which we don't want to have in a Qt class. And in fact I am NOT proposing to add such an alias at all, but to use std::unique_ptr as-is. 1) It's still NIH; Which is not bad per se, in absolute terms. * If it's worth economically is a question for who pays the bills. * If it's worth technologically: I still don't see a use case that * I can tell you for sure it's not worth from a learning (and teaching) point of view. 2) The probability of future C++standards adding features that won't be available in the Qt counterpart is 100%; They could be added, and the effort should be minimal (copy the code from STL). There's no "code from STL". The Standard is a specification, not code. If you meant to copy from an _implementation_: it has not happened in the last 9 years (see the examples I brought in the other email), what grounds do you believe it will start now? (Not to mention the legal problems associated with this.) 3) Explain why Qt should raise arbitrary interoperability barriers literally "for the sake of it"; We can easily provide static fromStdUniquePtr and toStdUniquePtr methods, and there wouldn't be a barrier. We could also use std::unique_ptr directly and there would be even less of a barrier. I asked why put this barrier in the first place, not how to reduce this barrier. (And I also asked about shared_ptr) 4) Please justify the teachability efforts involved in explaining all of the above to Qt users. You can explain it to our users by saying that we want a consistent API, and that while Qt is interoperable with the STL, it can be used without it (and as an alternative to it). Qt cannot be used without a Standard Library. The question for the future is how do we make the maximum out of it. 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] The future of smart pointers in Qt API
On 02/02/2020 17:38, Alberto Mardegan wrote: On 01/02/20 15:32, Giuseppe D'Angelo via Development wrote: Il 01/02/20 12:37, Alberto Mardegan ha scritto: Do we need to have such a counterpart? In my work experience, when I'm not allowed to use Qt and am restricted to the STL, all the times I had to use std::unique_ptr was to get the same behaviour as a QScopedPointer. So you never had to pass one to a function, return one from a function, create a vector of them? Color me *very* suspicious. Believe it or not :-) I find std::shared_ptr easier to use when passing pointers to and from functions. And I never needed to put them into an array. This is a logical fallacy; "I don't need it, noone else does". So, I don't really care about std::unique_ptr, but I like Vitaly's suggestion of having a QUniquePointer with a nice data() method. How about working with upstream and convincing them that having data() (in addition to get()) on smart pointers is a good idea? Is having data() the _only_ argument here? The STL could still add a method made up of two words in the future, and it's unlikely that they'll use camelCase (or that they'd accept a camelCase variant). And I still see no problem in that? What is the problem at looking a bit outside one's comfort zone (or one's bubble) and realizing that simply because the Standard Library uses snake_case, we can live with it just fine? 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] The future of smart pointers in Qt API
On 02/02/2020 18:17, Иван Комиссаров wrote: No one answered my question about QObject::deleteLater: And what about the QObject::deleteLater() method? Any ideas how this should look like with smart pointers? You can specify custom deleters for smart pointers. For QScopedPointer there's already a convenience class that does it: QScopedPointer ptr = ~~~; // ptr falls out of scope, deleteLater() is called on the pointee Such a convenience deleter should be moved to QObject, to be honest (and no, it's not usable as-is with std:: smart pointers). Note: I didn't review Daniel's proposal so I'm not sure if this would actually work in there. HTH, -- 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] The future of smart pointers in Qt API
Il 01/02/20 13:31, Allan Sandfeld Jensen ha scritto: On Samstag, 1. Februar 2020 10:15:02 CET you wrote: Il 01/02/20 09:27, Allan Sandfeld Jensen ha scritto: To me the name is still perfect. It makes perfect sense. Just because it is movable doesn't mean you move the object itself, a move moves the content of the object. So each move triggers a move of the payload of a scoped pointer to another scoped pointer in another scope. I never understood why anyone would think the name would make that impossible. The counter argument is: it would imply that the _pointer_ escapes the _scope_. Not the smart pointer, it never leaves. Only the raw pointer does, and only because you have moved it out of the scoped pointer, and it into a new one. This isn't a counter argument -- in a shared pointer, you share the _pointer_, not the smart pointer itself (you'll have several distinct smart pointer objects, but all sharing the same pointer). In a scoped pointer, you "scope" the pointer, not the smart pointer object. :-P This conversation is 9 years too old -- the ship has sailed. std::unique_ptr is the vocabulary type that is on every C++ book teaches, every C++ talk explains, every C++ project uses (all over the place inside Qt itself). Unless some extraordinary argument appears, that's the name that Qt should also use. It is still a terrible name. Unique pointer refers to something std::unique_ptr can abstractly achieve, but not what it actually is. With this I may agree. The mental exercise used here is not that the pointer itself is "unique" (whatever that means), but the ownership is unique -- and represented by the unique_ptr object itself. 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
Hi, Il 01/02/20 22:55, Vitaly Fanaskov ha scritto: The consensus was reached against such a decision. A scoped pointer should not be able to escape scope. Yes, in C++17 this is now not entirely true, but the name strongly implies it. Perhaps, it's a good time to reconsider it. Scoped pointer is redundant entity in light of modern C++. It's just an unique pointer without move semantic. If we're going for this logical fallacy, then let's up the ante: a unique pointer is just a shared pointer without copy semantics. Why not using shared pointers everywhere? Please, give me at least one example when I cannot replace scoped pointer with unique pointer without losing readability and maintainability. And an example where I cannot replace a unique pointer with a shared pointer without losing readability and maintainability? Unique pointer could "escape a scope" only explicitly. Like this? std::unique_ptr ptr = ~~~; return ptr; So I'm still not convinced that we need to have one more redundant entity. Which one would be the redundant one? We have more than enough. This is possible to introduce an alias just to keep naming convention people get used to, I guess, but I'm not sure if this is really required. About QUniquePointer: what's the point of reinventing std::unique_ptr under a different name? So, first of all, not reinventing. I'd say adopting. The main question I see through some your posts in this thread is "why do we need Qtish wrappers at all?". Correct me if I'm mistaken, please. That's the question indeed. What's the tangible net benefit of having a Qt wrapper? Until that I'll answer this question __ There are a few pros of having Qt wrappers around std smart pointers. To make it clear, saying "Qt wrapper" I mean a class that contains std smart pointer as a field and has more Qtish interface. Not inherits a std smart pointer. And I've asked: how this Qtish interface for std::unique_ptr be different exactly? Pros I can see: 1) Qt style STL has different naming convention that looks alien to Qt API. It leads to inconsistency. STL is not a part of C++ language itself and cannot be considered as a default standard. What? This is absurdly false -- the Standard Library is part of the C++ standard itself. The fact that some people might get used to some names doesn't mean that these names are good in terms of self-explanatory. > For example, how do I understand without documentation what does "weak_ptr::lock" do? Something like "asStrongRef" is easily understandable just by reading code. With this I can totally agree. As I said countless times, the only way to influence such naming decisions is working _with_ upstream (by the way, the meetings are pretty much public) and bringing your arguments on naming there. After, it's too late, and as an overall minority in C++ we'll get those decisions made by someone else and we'll just have to live with them. It's not a good position to be in. Between C++11, 14, 17 and 20, by heart I can only name _one_ thing that has been introduced in the Standard Library which has had an inspiration coming from Qt (C++20's std::map::contains()). Please also see this from the eyes of someone else who comes from a general purpose C++ background, where usage lock() is established (for how much absurd that naming choice is); then gets the Qt equivalent, and wonders why it _hasn't_ got lock(), despite Qt having 0.something% of the C++ market share. (I know QWeakPointer has got lock() now.) I'm not 100% sure who is responsible for naming STL classes and methods, but this person(s) did really good job in terms of reducing symbols count. I'm just wondering why not "w_p::l" instead of "weak_ptr::lock", it looks much shorter! In my opinion, we shouldn't sacrifice readability to reduce symbols count. The "who" is a lot of people. https://isocpp.org/std/the-committee After all, many Qt users get used to Qt naming convention and style. And again see this the other around too: many C++ users get used to the C++/Boost/Abseil/... naming convention and may find Qt ones "unusual". 2) Flexibility It will be much easier to extend or reduce interface if we need it. Changing implementation is also will be easier if someone needs to have a different smart pointers under the hood on some platforms. Changing the interface in any way which are incompatible with the Standard counterparts is a _terrible_ idea. It kills the principle of least surprise; it makes such facilities incompatible with the STL counterparts, preventing interexchange of data and code; and come Qt (N+1), it will prevent a clean pass of s/QtFoo/std::foo/g over the codebase. 3) Low maintenance costs We just need to replicate an API at first implementation. After that, introducing new methods that might occur in an upcoming standards should be easy enough. This is wishful thinking, or, famous last words.
Re: [Development] The future of smart pointers in Qt API
Il 01/02/20 12:37, Alberto Mardegan ha scritto: Do we need to have such a counterpart? In my work experience, when I'm not allowed to use Qt and am restricted to the STL, all the times I had to use std::unique_ptr was to get the same behaviour as a QScopedPointer. So you never had to pass one to a function, return one from a function, create a vector of them? Color me *very* suspicious. It's true that QScopedPointer offers only a subset of std::unique_ptr's functionalities, but,*for that subset*, its name is just perfect. That's why I wouldn't like to see it go away, or moved to a compat library. The same subset is available in the Standard Library. The type you're looking for is "const std::unique_ptr". So, I don't really care about std::unique_ptr, but I like Vitaly's suggestion of having a QUniquePointer with a nice data() method. How about working with upstream and convincing them that having data() (in addition to get()) on smart pointers is a good idea? Is having data() the _only_ argument here? 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
Il 01/02/20 12:44, Alberto Mardegan ha scritto: On 01/02/20 02:46, Giuseppe D'Angelo via Development wrote: About QUniquePointer: what's the point of reinventing std::unique_ptr under a different name? A Qt-ish API! Example? * Is it just going to be an alias, to be more Qtish? Then why QSharedPointer is NOT going to be an alias? * Is it not going to be an alias? NIH all over again? It's not clear to me what you mean by "alias"; if you mean a subclass, then I'd be against it, because there's a (very small indeed) risk that in the future the STL adds some methods that might conflict with ours, or would not be Qtish enough. I mean a type alias: using QUniquePointer = std::unique_ptr; If we can resue the STL implementation, that's a good thing, but it should be an implementation detail; and I don't think we should care about NIH, when we are talking of classes that are unlikely to pose a great maintenance burden. 1) It's still NIH; 2) The probability of future C++standards adding features that won't be available in the Qt counterpart is 100%; 3) Explain why Qt should raise arbitrary interoperability barriers literally "for the sake of it"; 4) Please justify the teachability efforts involved in explaining all of the above to Qt users. Cheers, -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
Il 01/02/20 09:27, Allan Sandfeld Jensen ha scritto: To me the name is still perfect. It makes perfect sense. Just because it is movable doesn't mean you move the object itself, a move moves the content of the object. So each move triggers a move of the payload of a scoped pointer to another scoped pointer in another scope. I never understood why anyone would think the name would make that impossible. The counter argument is: it would imply that the _pointer_ escapes the _scope_. This conversation is 9 years too old -- the ship has sailed. std::unique_ptr is the vocabulary type that is on every C++ book teaches, every C++ talk explains, every C++ project uses (all over the place inside Qt itself). Unless some extraordinary argument appears, that's the name that Qt should also use. 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
