Re: [Development] How qAsConst and qExchange lead to qNN
I don't want to take the Qt containers away from Qt users. I want to get rid of their use in our APIs, so that both the Qt implementation as well as our users are free to choose the best container for their needs instead of having to pick from one of the public Qt containers. I would like to know how that is supposed to work in practice. We have a lot of public API dealing with Qt containers all over. What are you going to do to, for example, to void addActions(const QList ); in qwidget.h? What should it look like when we're done and our users are free to choose the best container for their needs? Mind that I'm specially interested in this because I'm currently facing a similar problem, making different container types available in QML. QML has its own poor man's "range" type in the form of QQmlListProperty and it's terrible. >> Q_FOREACH > [I can make 100% correct predictions about changes I intent to push, > too. What's the point?] I have no desire to touch the implementation of Q_FOREACH, ever. I did, unwillingly, when its users suffered unnecessary pessimisations in the past, but the port to C++20 ranged-for-with-init is not of that kind. Waiting for someone to push a patch with code you've already outlined and then approving it is pretty much the same as changing it yourself. You just don't need any approval for that ... best regards, Ulf ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Meeting minutes from Qt Release Team meeting 08.11.2022
Qt 6.4 status: - Branching from '6.4' to '6.4.1' done - Final fixes for Qt 6.4.1 integrating - Target is to freeze the Qt 6.4.1 content Wed 9th November - Target is to release Qt 6.4.1 Tue 15th November Qt 6.5 status: - Public snapshot from 'dev' available and updated automatically - Preparations for 'platform and module freeze' -milestone ongoing * Will be in effect Fri 25th November ** All new modules needs to be in CI and qt5.git (if needed) at that point. Otherwise those will be postponed to Qt 6.6 (or with granted exception those can be taken in later to Qt 6.5) ** No provisioning changes between 'platform and module freeze' & beta1 release * Known new modules so far: ** QtgRPC ** Qt Quick Effect Maker Next meeting Tue 15th November 2022 16:00 CET br, Jani Heikkinen Release Manager irc log below: [17:01:13] akseli: alblasch: carewolf: The-Compiler: thiago: ping [17:01:38] jaheikki3_: pong [17:01:48] jaheikki3_: pong [17:02:12] Time to start qt release team meeting [17:02:17] On agenda today: [17:02:22] Qt 6.4 status [17:02:26] Qt 6.5 status [17:02:39] Any additional item to the agenda´? [17:03:58] Ok, let's start from qt 6.4 status [17:04:18] Branching from '6.4' to '6.4.1' done [17:04:44] Final fixes for Qt 6.4.1 integrating [17:05:02] Target is to freeze the Qt 6.4.1 content tomorrow [17:05:39] And target is to release Qt 6.4.1 Tue 15th November as planned [17:06:00] That's all about Qt 6.4 status at this time. Any comments or questions? [17:08:00] Ok, then Qt 6.5 status [17:08:21] Public snapshot from 'dev' available and it will be updated automatically [17:08:34] Preparations for 'platform and module freeze' -milestone ongoing [17:08:56] it will be in effect Fri 25th November [17:09:08] And it means: [17:09:17] All new modules needs to be in CI and qt5.git (if needed) at that point [17:09:36] otherwise those will be postponed to Qt 6.6 (or with granted exception those can be taken in later to Qt 6.5) [17:09:53] And no provisioning changes between 'platform and module freeze' & beta1 release [17:10:17] Known new modules for Qt 6.5 at the moment: [17:10:29] QtgRPC [17:10:36] Qt Quick Effect Maker [17:11:08] That's all what I have for Qt 6.5 status at this time. Any comments or questions? [17:11:15] not from me [17:12:19] It was all at this time so let's end this meeting now & have new one tue 15th November at this same time [17:12:29] Thanks for your participation, bye! [17:12:35] bye ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] How qAsConst and qExchange lead to qNN
Hi Andre, When you say > You, /personally/ /you/, have been the driving force I think you and Kevin are giving me credit where none is due. The Qt containers changed multiple times before the Qt project was even formed and yours truly could have possibly had any influence on their design. Interestingly, when you say > Staying with unmodified Qt 4 containers would very likely just have > worked in Qt 6 and not have caused any problems for users upgrading Two things spring to mind: First, that it's probably not a coincidence that stability came right after Qt adopted basically the STL model. QVector was std::vector + COW, QMap was std::map + COW, and the old QGList experiment was finally put to rest as Q3PtrList. Second, that I completely agree with you. I think the decision to make Q6List be Q5Vector and add a prepend optimisation was a major mistake. We should have told people to prepare for QList -> QVector by using auto when receiving QLists from Qt, added implicit conversions between them for when users were passing in QLists, and then we should have cleaned _our_ basement by porting away from QList to QVector (we anyway did that), but leave Q5List as-is in qt5compat. I think you will find me and Peppe on record on this mailing list in the run-up to Qt 6 asking exactly that. Alas, TPTB decided, instead, to - reuse the QList name for QVector - _not_ provide Q5List in qt5compat thus breaking not only our own uses (which we had to do, anyway, in the move from QList to QVector), but also our users' code. Silently, I hasten to add. Finally, when you say > I haven't checked > explicitly, but my best guess is that Qt 4.0 (2005(!)) would > container-wise be "good enough" for my current needs. We're in violent agreement, too. Why take them from someone for whom the Qt4 containers are good enough™? From my pov, the Qt containers can be moved into a libQtQTL or something like that and enjoy their life as a slightly different approach to the STL containers. Then users that don't need Qt per-se could opt-in to using the Qt containers _only_ (and a similar argument can be made for the Qt string types; libQt7Strings; CopperSpice says to say hello), potentially drawing in more users, if they, indeed, serve a different audience than the STL ones. What I _do_ care about is that Qt atm doesn't let the user /choose/. Because of their ubiquitous use in Qt APIs, the user is forced to use the Qt containers, even though he may have a need for the STL containers (interop with 3rd-party libraries, allocators, > 2Gi elements, etc). I don't want to take the Qt containers away from Qt users. I want to get rid of their use in our APIs, so that both the Qt implementation as well as our users are free to choose the best container for their needs instead of having to pick from one of the public Qt containers. Let each user choose among the Qt, STL, Boost, Abseil, and Folly container classes on a level playing field. Now, if you like an intellectual challenge, the please explain to me how Qt's insert-or-assign is either more convenient, easier, more user-friendly, more idiomatic, or whatever, than STL's insert-or-no-op If, as you say, the Qt containers are carefully designed to a different set of goals, then I'd really like to know what the goal looks like that made Qt choose this design. To summarize: - I will not accept responsibility for any container rewrites in any of the Qt major version changes. I was not involved in any of these decisions, and where I was involved in the discussion, my suggestions were not followed. - I do not want to take Qt containers away from Qt users. Instead, I want our APIs to stop forcing our users (and us) to use (owning) Qt containers. Finally, >> Q_FOREACH > [I can make 100% correct predictions about changes I intent to push, > too. What's the point?] I have no desire to touch the implementation of Q_FOREACH, ever. I did, unwillingly, when its users suffered unnecessary pessimisations in the past, but the port to C++20 ranged-for-with-init is not of that kind. > string UDLs From my POV, we were fixing up a prior experiment-gone-wrong. I laid out the problems of the _qs UDL design in https://lists.qt-project.org/pipermail/development/2022-March/042335.html, so I won't repeat them here. Thanks, Marc On 08.11.22 20:32, A. Pönitz wrote: > On Mon, Nov 07, 2022 at 08:15:58PM +, Marc Mutz via Development wrote: >> Hi all, >> >> SCNR taking the proffered bait: >> >> On 07.11.22 18:51, Edward Welbourne wrote: >>> For Qt to remain relevant in the rapidly-evolving C++ landscape, it >>> needs to change; but one of its strong selling-points has long been its >>> conservatism in API and ABI, that lets working code keep working. >> >> I've not been around for the Qt 1 → Qt 2 port, but I did participate in >> all of the Qt 2 → Qt 3, Qt 3 → Qt 4, Qt 4 → Qt 5 and Qt 5 → Qt 6 >> transitions. Speaking with my Qt user hat on, I'm
Re: [Development] INTEGRITY help needed: IPC & QT_CONFIG weirdness
On Tuesday, 8 November 2022 12:59:39 PST Niclas Rosenvik wrote:
> /home/qt/work/qt/qtbase/build/target/include/QtCore/../../../../src/corelib/
> ipc/qtipccommon.h:125:21: warning: 'QNativeIpcKey::TypeAndFlags::type' is
> too small to hold all values of 'enum class QNativeIpcKey::Type'
This one is expected and intentional. Type is an enum class with quint16
underlying type, so it cannot store all 65536 values on 15 bits.
> Is this the error that causes QNativeIpcKey::Type::SystemV to be the
> value you mentioned?
No, it isn't. The values in question are all less than 9 bits in size.
The issue appears to be that QT_POSIX_IPC isn't #define'd in qtcore-config.h.
This is the configure.cmake content:
qt_feature("ipc_posix"
LABEL "Defaulting legacy IPC to POSIX"
CONDITION TEST_posix_shm AND TEST_posix_sem AND (
FEATURE_ipc_posix OR (APPLE AND QT_FEATURE_appstore_compliant)
OR NOT (TEST_sysv_shm AND TEST_sysv_sem)
)
)
qt_feature_definition("ipc_posix" "QT_POSIX_IPC")
>From the cmake output, we should have:
TEST_posix_shm = ON
TEST_posix_sem = ON
TEST_sysv_shm = OFF
TEST_sysv_sem = OFF
So this condition should have been TRUE. But isn't.
BTW, the iOS build said:
Defaulting legacy IPC to POSIX . yes
So the middle condition of appstore-compliance did work.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] INTEGRITY help needed: IPC & QT_CONFIG weirdness
On Tue, 08 Nov 2022 10:35:08 -0800 Thiago Macieira wrote: > On Saturday, 5 November 2022 22:59:06 PST Thiago Macieira wrote: > > Ok, now I need QNX help from build > > https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1679395790 > > ping, anyone? > > I've updated the configure summary to include whether the key was > enabled and it was indeed NOT enabled: > > -- Performing Test HAVE_sysv_shm > -- Performing Test HAVE_sysv_shm - Failed > -- Performing Test HAVE_sysv_sem > -- Performing Test HAVE_sysv_sem - Failed > -- Performing Test HAVE_posix_shm > -- Performing Test HAVE_posix_shm - Success > -- Performing Test HAVE_posix_sem > -- Performing Test HAVE_posix_sem - Success > [...] >Defaulting legacy IPC to POSIX . no > > This is the last remaining failure in the patchset. If no one > suggests a fix, I'll create a bug report for Someone Else™ and > QEXPECT_FAIL the issue. > Hi Thiago, I just looked at the build log at: https://testresults.qt.io/coin/api/results/qt/qtbase/31eb60ef6fa413035971e47cc3f0eccaeba2a4dd/LinuxUbuntu_20_04x86_64QNXQNX_710arm64GCCqtci-linux-Ubuntu-20.04-x86_64-50-ab8bebDisableTests_UseConfigure/fbbf955d4168c54abbfb4dde4ba71ab3b3195ce0/build_1679395838/log.txt.gz It includes this: /CMakeFiles/Core.dir/cmake_pch.hxx -Wp,-MD,src/corelib/CMakeFiles/Core.dir/ipc/qsharedmemory_posix.cpp.o.d -Wp,-MT,src/corelib/CMakeFiles/Core.dir/ipc/qsharedmemory_posix.cpp.o -Wp,-MF,src/corelib/CMakeFiles/Core.dir/ipc/qsharedmemory_posix.cpp.o.d -o src/corelib/CMakeFiles/Core.dir/ipc/qsharedmemory_posix.cpp.o -c /home/qt/work/qt/qtbase/src/corelib/ipc/qsharedmemory_posix.cpp agent:2022/11/06 03:52:38 build.go:394: In file included from /home/qt/work/qt/qtbase/build/target/include/QtCore/qtipccommon.h:1, agent:2022/11/06 03:52:38 build.go:394: from /home/qt/work/qt/qtbase/src/corelib/ipc/qsharedmemory.h:7, agent:2022/11/06 03:52:38 build.go:394: from /home/qt/work/qt/qtbase/src/corelib/ipc/qsharedmemory_posix.cpp:6: agent:2022/11/06 03:52:38 build.go:394: /home/qt/work/qt/qtbase/build/target/include/QtCore/../../../../src/corelib/ipc/qtipccommon.h:125:21: warning: 'QNativeIpcKey::TypeAndFlags::type' is too small to hold all values of 'enum class QNativeIpcKey::Type' agent:2022/11/06 03:52:38 build.go:394: Type type : 15; agent:2022/11/06 03:52:38 build.go:394: ^~ agent:2022/11/06 03:52:39 build.go:394: [277/1163] /opt/qnx710/host/linux/x86_64/usr/bin/q++ -Vgcc_ntoaarch64le -Wc,-isysroot,/opt/qnx710/target/qnx7 -lang-c++ -DCore_EXPORTS -DPCRE2_CODE_UNIT_WIDTH=16 -DQT_ASCII_CAST_WARNINGS -DQT_BUILDING_QT -DQT_BUILD_CORE_LIB -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_UP_TO=0x05 Is this the error that causes QNativeIpcKey::Type::SystemV to be the value you mentioned? warning: 'QNativeIpcKey::TypeAndFlags::type' is too small to hold all values of 'enum class QNativeIpcKey::Type' I don't know how to fix it but it might be a step in the right direction, if it is the error. Regards, Niclas Rosenvik ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] How qAsConst and qExchange lead to qNN
On Mon, Nov 07, 2022 at 08:15:58PM +, Marc Mutz via Development wrote:
> Hi all,
>
> SCNR taking the proffered bait:
>
> On 07.11.22 18:51, Edward Welbourne wrote:
> > For Qt to remain relevant in the rapidly-evolving C++ landscape, it
> > needs to change; but one of its strong selling-points has long been its
> > conservatism in API and ABI, that lets working code keep working.
>
> I've not been around for the Qt 1 → Qt 2 port, but I did participate in
> all of the Qt 2 → Qt 3, Qt 3 → Qt 4, Qt 4 → Qt 5 and Qt 5 → Qt 6
> transitions. Speaking with my Qt user hat on, I'm terribly sorry to
> inform y'all that Qt has largely _failed_ to keep working code working.
> Sure, a trivial QWidgets program from the mid-90s may still compile and
> work in Qt 6, but as soon as said program touches Qt container classes,
> it's game over.
Staying wiht unmodified Qt 4 containers would very likely just have
worked in Qt 6 and not have caused any problems for users upgrading
their applications during the last 15 years.
> Both Boost and C++ itself have a much better track record of keeping
> working code working, let alone any random C library. And this is
> actually a fair comparison, because we're comparing apples (STL
> containers) to apples (Qt containers).
No. Goals of STL and Qt containers are /quite/ different.
Qt offers convenience and ease of use while still being "good enough"
at performance for normal use. STL can give better performance in some
cases, but needs more handholding, more alertness from the user, and
it's easier to get things completely wrong, also performance-wise.
This is absolutely not "apples vs apples", rather (tr("Nicht alles, was
hinkt, ist ein Vergleich, aber:")) "cars vs motorcycles": Sure, they have
a lot in common, but none is uniformly "better" than the other.
> Let's not kid ourselves thinking Qt is any special here. It isn't. We
> mustn't just look at one major release cycle. Qt loses projects at every
> new major release, because changes to non-core-competency parts of the
> API make porting unnecessarily complicated, so that unmaintained or
> understaffed projects[1] cannot muster the strength to be ported.
I consider this an absurd line of reasoning coming from /you/.
You, /personally/ /you/, have been the driving force behind a
significant amount of /from my perspective/ unnecessary and absolutely
unwelcomed changes like the removal of Q(5)List that I predicted to be
and now apparently _is_ hampering "understaffed projects" (which in my
book covers pretty much /every/ open source projects and quite a few
commercial ones) to move from Qt 5 to Qt 6.
This "loss of projects" is not the consequence of any natural law or
divine intervention. Even "understaffed projects" can typically "muster
the strength" to do _necessary_ adaptations to _critical_ problems.
However, it is completely no surprise _to me_ that they do not want to
jump through any hoop that is effectively only busy-work, not solving
any real problem.
> My goal with qNN is to make porting away _simple_. All that's required
> is to s/qNN::/std::/ and be done. No deprecation, no sanity bot, not
> even the need for local code knowledge; just simple global textual
> replacement. And no regressions, if you first switch to C++NN, and only
> then do the replacement. We can even retain the qNN symbols until Qt
> requires C++(NN+3), because the qNN headers will be nothing but a long
> list of using std::foo; at that time.
>
> It's not really acceptable that such trivial ports should be subjected
> to all the same (or, apparently since it's done in bulk, more
> restrictive) requirements than for deprecation of core-competency APIs.
> The more so as I must have missed the outcry of developers when we inflicted
_To me_ it is not really acceptable that (parts of) qtbase are treated
as playground for experiments. [And _I_ _do_ think that e.g. calling
"string literal qualifications du jour" that barely last for a year "an
experiment" is fair].
In my world, deprecations ("trivial" or not) _in a library_ should only
happen as a consequence of an unexpected _and_ fundamental _and_ otherwise
unfixable flaws in the API, causing _real_ (not "imagined") harm for "a
lot" of users. This should never be used wantonly, and definitely not
pre-planned.
> To hold users, a project must maintain _long-term_ API stability, not
> rewrite the container classes for every major release.
... g ...
> So, sorry, but as a user of Qt I'd really like to use those stable STL
> classes, if only your volatile APIs let me. I'd rather I had done that
> _one_ port between Qt 1 and 2 than all those ports in Qt 1-6.
Again, /you/, /personally/ /you/, have been /actively/ involved and
promoted and/or done part of these /breaking/ changes. I haven't checked
explicitly, but my best guess is that Qt 4.0 (2005(!)) would
container-wise be "good enough" for my current needs. And it's not that
STL has't changed since then...
Re: [Development] INTEGRITY help needed: IPC & QT_CONFIG weirdness
On Saturday, 5 November 2022 22:59:06 PST Thiago Macieira wrote: > Ok, now I need QNX help from build > https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1679395790 ping, anyone? I've updated the configure summary to include whether the key was enabled and it was indeed NOT enabled: -- Performing Test HAVE_sysv_shm -- Performing Test HAVE_sysv_shm - Failed -- Performing Test HAVE_sysv_sem -- Performing Test HAVE_sysv_sem - Failed -- Performing Test HAVE_posix_shm -- Performing Test HAVE_posix_shm - Success -- Performing Test HAVE_posix_sem -- Performing Test HAVE_posix_sem - Success [...] Defaulting legacy IPC to POSIX . no This is the last remaining failure in the patchset. If no one suggests a fix, I'll create a bug report for Someone Else™ and QEXPECT_FAIL the issue. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] IMPORTANT: Gerrit host keys have changed
Hi, This information was already published on this list, but it seems to have been missed by a handful of key players (possibly because it was only included in the Maintenance break email). Risking informing you all twice, I’ll reiterate the memo here. — IMPORTANT: Server host keys have been updated. When doing a git command you might get warning like: @@@ @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is SHA256:EPuL0PAbNuXXoye7X93ARF7/XALxA5XNAaE3p6M/L3g. Please contact your system administrator. — Jukka Jokiniva, Gerrit Admin (original email: https://lists.qt-project.org/pipermail/development/2022-November/043215.html) — IMPORTANT: Server host keys on port 29419 [corrected to 28418 in a later email] will be updated to support modern algorithms. Also the existing RSA key will be updated to a longer key size. After the change the git commands may fail with errors about mismatched or changed host keys or host identification. To fix this remove locally the old known host key (on Linux based remove the corresponding line in ~/.ssh/known_hosts -file) and verify the new one (git will prompt for verification). Here are the finger prints of the keys that will applied on 7-Nov: ssh_host_ecdsa_384_key 384 SHA256:yMnqjnsJU0y6kfiyQQu8pYNGPFE7av5QxbeLdjTKNmk (ECDSA) ssh_host_ecdsa_521_key 521 SHA256:kytLsqmLdG1KXLO/s3OxOajTYqf1+n7+YqqbOUzNbtE (ECDSA) ssh_host_ecdsa_key 256 SHA256:El3+EYlXAGylCVo/Y/WYzPg7tS4fjejkepO1JVXUkb0 (ECDSA) ssh_host_ed25519_key 256 SHA256:DwwqNluQyJVkOk+3bFMK6NwWYIGjMnqGP+R0k59e3CY (ED25519) ssh_host_rsa_key 4096 SHA256:EPuL0PAbNuXXoye7X93ARF7/XALxA5XNAaE3p6M/L3g (RSA) — Jukka Jokiniva, Gerrit Admin (original email: https://lists.qt-project.org/pipermail/development/2022-November/043213.html) Cheers, David Skoland ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] I ❤️ Qt containers! :) (was: How qAsConst and qExchange lead to qNN)
> On 8 Nov 2022, at 14:25, Volker Hilsheimer via Development > wrote: Tor Arne ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] I ❤️ Qt containers! :) (was: How qAsConst and qExchange lead to qNN)
> On 7 Nov 2022, at 21:15, Marc Mutz via Development
> wrote:
[…]
> Anyway; to all those who disagree when I say Qt should concentrate on
> its core competencies and stop meddling with container classes, shared
> pointers, etc, I say this: which of the two universes above would you
> rather have lived in these past 30 years? A or B? Be truthful!
Historically, STL implementations were unusable and unreliable for cross
platform development (we supported HP-UX, AIX, SGI, Sun back in those days),
and generally incomplete (only a few associative containers pre-C++11). So, 30
or 20 years ago, or perhaps up to C++11 and until we could drop commercial Unix
systems as irrelevant (esp for Nokia’s plans; although no idea about the
quality of the STL for Symbian C++), the STL wasn’t really much of an option.
However, this is a more fundamental question about what we try to achieve with
Qt. Qt has never tried to be a C++ library that follows the design principals
of the std library. In many cases, we don’t even care that much about the
single responsibility principle (hello, QWidget). Qt container classes have
always been more than a dumb storage of data on top of which algorithms
operate. QString is a very rich class with tons of functionality, specific to
text handling. std::string is a sequence of characters. Working with QString vs
std::string to deal with user-provided text input requires rather completely
different mindsets.
Our core competence of designing intuitive APIs does not exclude container
classes. That’s why with Qt containers, we can write
if (list.contains(value)) {
// …
}
rather than
if (std::find(list.begin(), list.end(), value) != list.end()) {
// ...
}
Perhaps it makes me an inferior C++ developer, but I rather prefer the former.
Well, std::map got a contains(), and std::string a starts_with in C++ 20, only
25 years late(r).
Indeed, sometimes that convenience means that our users, and we ourselves, can
do something silly like:
if (map.contains(key)) {
value = map.value(key);
// do stuff with value
}
Convenience is no excuse for us as developers of Qt to be sloppy. It is also no
excuse for ignoring the new features we get into our toolbox when we move to
C++ 20 or 23. But that C++ 20 finally introduces std::map::contains (but not
std::vector::contains…), or adds std::span, is also no excuse for us to toss
our own designs out of the window, and to demand that all Qt users must embrace
the STL instead.
One of Qt’s goals has always been to make C++ accessible for people that come
from other languages, with a programming model that is not rooted in how the
C++ standard library does things. That programming language used to be Java -
hence our Java-style iterators in Qt containers. Today, people perhaps rather
learn programming with Python in school. There will always be more people that
have learned programming with other languages, than those that have carefully
studied the C++ standard and the impact of various constructs in Compiler
Explorer. We must make it easy for the former, while also enabling the latter.
And there are the practical reasons why I don’t want to replace QList with
std::vector and QHash with std::unordered_map: we store our data structures in
the d-pointer, and we want to stay flexbile wrt the actual stored type. So
copy-elision and return-value-optimization don't buy us much: we need to return
copies of containers from our property getters. Not const references to
containers, and not temporary lists that can be moved out. So we do need
reference counting.
For the here and now, and the last 25 years of Qt and C++, it’s not helpful to
argue that we will soon be able to return a type-erased span and get rid of
“horrible and inefficient” APIs returning owning containers. std::span is a new
tool, opening up new opportunities; the expressiveness of e.g. C++ ranges might
even make it much easier for someone coming from e.g. Python to use Qt, while
allowing us to write much more efficient code. So we do need to consider how we
name and design our APIs today so that we can add new APIs to unlock that power
in the future. And we need to keep looking for ways to improve what we have -
with extra awareness of what potential changes mean for our users and
co-contributors.
Those improvements cannot require that we force everyone to change significant
amounts of existing code, all the time; or that they have to regularly unlearn
established Qt patterns; or that they have to live without the convenience.
Yes, I’m biased, but I honestly don’t see any universe where a Qt without our
implicitly shared, owning, old-fashioned containers, and instead with only STL
containers and programming paradigms, would have been as easy, or as much fun,
to use.
Volker
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] How qAsConst and qExchange lead to qNN
-- Alex > -Original Message- > From: Development On Behalf Of > Volker Hilsheimer via Development > Sent: Monday, 7 November 2022 16:51 > To: Marc Mutz ; development@qt-project.org > Subject: Re: [Development] How qAsConst and qExchange lead to qNN > > > On 4 Nov 2022, at 16:00, Marc Mutz via Development project.org> wrote: > > > > Hi, > > > > After getting my head washed by Volker, lemme provide background on > > these two functions. > > Thanks for the context, Marc! > > > TL;DR: we created real maintenance and porting problems by not > > removing stop-gap functionality in a timely fashion, qNN presented as > > a way to ensure this won't happen again. > > > > Both qAsConst and qExchange are 1:1 reimplementations of std > > functionality we couldn't rely on back then (as_const is C++17 and > > exchange is C++14), so they're exactly equivalent to the std versions. > > Or were, when they were added. > > > > Neither std::as_const nor qAsConst have changed, so the replacement is > > easy: s/qAsConst/std::as_const/. It cannot not compile because > > qAsConst comes from qglobal.h and that transitively includes > > . This is what was intended from the get-go: > > > The open question is whether and when we should deprecate such a stop-gap > 1:1 reimplementations of std functionality. How to deprecate is now well > documented, but the wiki starts with the process of doing so once we concluded > that we shall. It doesn’t give us any guidance yet on how to come to that > conclusion. I had to ask Volker which wiki he refers to and maybe it is the same for somebody else too. The URL is https://wiki.qt.io/Deprecation > When it’s time to phase out one of our own qNN implementations, then > > 1) propose the change here first to raise awareness, and to give people time > to > ask questions and/or raise objections > > Even if the people doing the work all agree, a lot of maintainers and > contributors will still be impacted (at least by the tool being removed). The > proposal should come with some data about how prevalent the usage of the > relevant construct is in Qt. It makes a difference whether we’d have to touch > a > few dozen lines, or several hundred to remove all usage. > > 2) If possible, add a warning to the sanity bot so that no new usage is added > > This is trivial in some cases, not so trivial in others. Rationale: For > changes that > impact a larger amount of code, there’ll be plenty of time between those > changes getting merged, and the old Qt-implementation ultimately getting > removed or fully deprecated (which we can’t/shouldn’t do while we still have > usage in Qt itself). For example, we now have some qAsConst back in the qtbase > code. I support this. In particular, the open communication before the fact is the key here. Let's face it, Qt is large enough that it cannot be expected that everybody knows what's going on in all the modules and such changes may never hit a developer's radar until after the merge and its enforcement. I propose we add the gist of Volker's proposal to the deprecation wiki mentioned above. > Whether we then do a bulk replacement in Qt, or whether we just stop using old > stuff in new code and phase it out over time as we touch code (until here’s > perhaps little enough left to make a bulk change), depends on the discussion. > If > we do make a bulk change, then making that change in stable branches to avoid > cherry-picking conflicts would probably be ok as well (unless those branch > can’t > use the new C++ version yet). Though Volker kind of implies that his two rules might lead to cherry-picking back into older releases, I would like to see this as explicitly mentioned option wherever we document the rules. > From: Development On Behalf Of > Marc Mutz via Development >#define Q_FOREACH(decl, expr) \ > for (const auto _q_foreach_c = expr; decl : _q_foreach_c) > > And I'd probably approve it, because then that thing can actually just be > replaced > with the expansion everywhere, and then, finally, be deleted. Considering the above, this kind of change would have to be brought up to the mailing list and be discussed before any approval is given. -- Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
