Re: [Development] Decrease amount of qt releases in online installer
On Wed, 21 Feb 2024 at 14:33, Jani Heikkinen via Development wrote: > > What kind of performance issues are we talking about? > > It takes quite a time to show all releases when you select 'archive' > category. With latest online installer this is already much better than > earlier but it still takes some time and it's a bit annoying... While I'm vaguely aware of various challenges in trying to apply filterings and mappings to the available-package metadata that the installation system has, I would highly recommend exploring some technical alternatives to solve that problem. I would think we could, even with the limitations of the current system, change that operation so that it shows a first fistful of archived releases, and separately allows showing all of them. Furthermore, the slowness of that operation suggests that that view of the installer populates much more model data than it actually really needs for displaying the available releases. I have no particular problem removing e.g 6.0, 6.1, and 6.2. Good riddance. 5.12 is a completely different case, though. And such removals would really be temporary measures, over time we are just going to end up with the same problem. So yeah, overall, I'd like us to investigate the possibilities of providing filtered views that can be multi-step-expanded to show more of the available options, rather than just outright removing the older releases as a choice. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Can we remove recommendation against unnamed namespaces from Qt coding conventions?
On Wed, 21 Feb 2024 at 21:38, apoenitz wrote: > >Use unnamed namespaces for all internal/non-exported entities. Functions > > can > >alternatively be marked `static` in the global namespace. Marking > > functions > >`static` also in the unnamed namespace can help readability, > > particularly in reviews. > > That's technically an option, but again not a good one in my book. There is no > advantage /known to me/ /for functions/ to be in the anonymous namespace > instead > of being 'static', and I listed a few cases where there are disadvantages. > > This change also does not solve the "problem" of having /different/ rules than > the (self-proclaimed...) "Core Guidelines" which was - to me - the main reason > for the proposed change. Well.. ..a recognized problem with the Core Guidelines is that not all of the guidelines in it come with the strongest of rationale, some of them are highly stylistic, and biased towards certain author preferences that don't exactly withstand hard scrutiny. The cost of symbols in intermediate build artifacts is one of the things that a particular origin of some of these guidelines, namely portions of "C++ Coding Standards: 101 Rules, Guidelines, and Best Practices" was somewhat ill-equipped to consider in sufficient detail. So, I highly recommend taking the Core Guidelines with quite a pinch of salt, in fact a bucket, not a pinch. They haven't been field-tested in serious anger. They might look like good ideas, but they might not work where the real rubber hits the road. My favorite example is https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-dynamic_cast It basically bans static_cast downcasts in a class hierarchy, so despite quickly mentioning "using CRTP carefully", it makes very strong insinuations of CRTP being banned. The problem is You Can't Do That, you can't use a dynamic_cast in a whole lot of class hierarchies because they aren't polymorphic, and the rule is very unclear about what using CRTP "carefully" means. The C++23 "deduced this" fixes the problem, removes the need to do such static downcasts, and removes the need for C, R, and P in CRTP. :) Nevertheless, that's a golden example of a Core Guidelines rule that you, after considering adopting it everywhere in your code, must deem nonsense, despite all the lofty hopes of the authors of these rules being infallible expert programmers who know exactly what it's like to face real-life engineering problems day in day out. I trust you can figure from all those colorful words whether I really think those authors are exactly that, or perhaps sometimes less so. :) -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Can we remove recommendation against unnamed namespaces from Qt coding conventions?
On Wed, 21 Feb 2024 at 19:56, Thiago Macieira wrote: > > On Wednesday, 21 February 2024 09:19:19 PST Mathias Hasselmann via Development > wrote: > > How that? > > > > https://wiki.qt.io/Coding_Conventions#Things_to_avoid says: > > > > "Avoid the use of anonymous namespaces in favor of the static keyword if > > possible." > > Back in the day, this was a better suggestion. Now, it's equivalent so it's > distinction without a difference. Not quite. I happened to be the evil NB representative who convinced WG21 to take a serious look at undoing the deprecation of static in namespace scope in favor of using unnamed namespaces, and this Core Issue elaborates why: https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#174 To what extent the second bullet is relevant any more, I don't know. But for compatibility reasons, and not just for legacy compatibility reasons, the distinction isn't without a difference, because there is a difference in some code not being able to use unnamed namespaces. Now, having said that, that doesn't mean we couldn't recommend using unnamed namespaces instead of static in namespace scope, for our own new C++ code. We technically could, but as Andre says, there are plausible reasons why some programmers might just prefer using simple statics instead of wrapping in unnamed namespaces. In general, I would prefer style guides and design guides and programming guides to help programmers avoid mistakes, and to write good code. Using static in a namespace scope isn't a mistake, and it isn't bad code. It's a simple facility that various programmers easily understand, and use correctly. Are unnamed namespaces strictly better than using static in namespace scope? I don't think so. Are unnamed namespaces strictly worse than using static in namespace scope? I don't think so, either. What I do think is that the trade-offs of either of them aren't obviously applicable to every situation. And as Andre points out, there are trade-offs that aren't just differences in semantics. It sure looks like we should certainly make *some* change in those conventions, because the referred standardese, which is now [basic.link]/4, certainly doesn't give names declared in an unnamed namespace external linkage. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] 6.7 FF vs. C++20 comparisons
On Sat, 16 Dec 2023 at 13:22, apoenitz wrote: > > On Fri, Dec 15, 2023 at 05:40:28AM +, Marc Mutz via Development wrote: > > On 13.12.23 18:36, Thiago Macieira wrote: > > > So, +1 for me on going ahead. > > > > Thanks! > > > > Is anyone else here for/against? > > To me this doesn't look like a new feature, so I don't see the feature freeze > blocking this formally. I don't see how it's not a new feature. "Convert more classes to opt in to C++20 three-way comparison" reads like a new feature to me for every word of it. > Maybe I am just generally lacking a certain sense of urgency here to have > this kind of changes, but I think it would be better to avoid the risk by > simply not doing it. I don't understand why it needs to be rushed into 6.7, instead of doing it without such rush for 6.8. Thus my take on this is -1. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Removal/deprecation of OpenSSL 1 in Qt
On Thu, 7 Dec 2023 at 12:33, Giuseppe D'Angelo wrote: > * For how long is QNX going to support OpenSSL 1? Is OpenSSL 3 support > on the radar? Yes, it's on the radar for QNX 8, which is not released yet. > Is there an online resource showing their commitment at > maintaining it? Is there the possibility of just building+shipping > OpenSSL 3 outside of what it's provided by the base OS? Well, like it is on Linux distros, building and shipping it as a replacement is not easy, and building and shipping it alongside is not easy either. > * For how long are *we* going to support QNX and OpenSSL 1 on there? Until QNX 8 ships. > * What about other platforms? Maybe we should keep OpenSSL1 support in 6.5 throughout the lifetime of that LTS. > * Can we put this "contract" in the docs? Sure seems like it would be a good idea to revisit this for the next LTS in any case. Make that the point where we drop OpenSSL1 regardless of whether Blackberry has managed to ship QNX 8. That's different from doing it in a patch release, or backporting the drop to everywhere. We can plausibly say at that point that we'll just drop it. > > I don't quite follow why the revert "must" include making OpenSSL1 > > entirely an opt-in. > > That doesn't change anything in how we build our release packages, at > > the end of the day. > > Innocent users should just build with an OpenSSL3-enabled system. > > Innocent users may have their own build scripts that pull OpenSSL 1 and > build Qt against that, without realizing that they're playing with fire. > We should never expose users to insecure defaults, hence the opt-in > flag, and a build error if you ask for autodetection and only OpenSSL 1 > is found. Well, okay then. Patch it first so that the opt-in supersedes autodetection but the autodetection is still there, then patch coin so that everything in it that needs this uses the opt-in, then drop the autodetection. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Removal/deprecation of OpenSSL 1 in Qt
On Thu, 30 Nov 2023 at 12:52, Giuseppe D'Angelo via Development wrote: > > Hi, > > OpenSSL 1 has reached EOL last September: > > > https://www.openssl.org/blog/blog/2023/09/11/eol-111/ > > > Qt has supported OpenSSL 3 for a while, and so last week I pushed a > patch to drop OpenSSL 1 support from Qt. "This has made a lot of people > very angry and been widely regarded as a bad move." > > > It turns out that not every platform officially supported by Qt ships > OpenSSL 3 yet. Some of these platforms are promising to maintain OpenSSL > 1 for a little while longer, for instance Ubuntu 20.04 LTS: > > > https://canonical.com/blog/running-openssl-1-1-1-after-eol-with-ubuntu-pro > > > How to move forward from here: "revert the patch", sure, but also not so > fast: > > * First and foremost, I'd like a semi-formal insurance from Qt SSL > maintainers that they're willing to maintain OpenSSL 1 code in Qt as > long as needed. This should be done publicly, in docs + blog posts, > because users are going to depend on this information. > > * For "how long" is that exactly? Also a very good question. Can we > gather 1) which supported platforms are still offering only OpenSSL 1, > and 2) for how long do they plan to support OpenSSL 1, and 3) for how > long Qt would like to support these platforms? (Basically, assessing > whether the "insurance" above is realistic) > > * Then, a plain revert isn't a good idea either: the whole point of the > original commit is that using OpenSSL 1 is outright dangerous if you > don't know what you're doing. (Using unmaintained security-sensitive > code is a terrible idea). Therefore, a revert must also include make > OpenSSL 1 entirely opt-in (cmake switch), and not using any automatic > detection whatsoever: users of Qt should never ever be enabling it "by > accident". Well, this is straightforward in the sense that QNX doesn't support openssl3 yet. Dropping OpenSSL1 support is dropping support for TLS on QNX, and we don't want to do that. I don't quite follow why the revert "must" include making OpenSSL1 entirely an opt-in. That doesn't change anything in how we build our release packages, at the end of the day. Innocent users should just build with an OpenSSL3-enabled system. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtFluentMQ
On Tue, 29 Aug 2023 at 13:28, Volker Hilsheimer via Development wrote: > > +1 in general. Likewise, +1 in general. My additional two cents: I have participated in Qt-using projects that did communications between vehicles and a back-end using AMQP, and used AMQP between back-end microservices. At certain scales and transactional data integrity requirements a message queue facility becomes pretty much a must-have, so having well-integrated Qt support for various message queue solutions seems like a fantastic addition. As far as the commercial aspects go.. ..I can't instantly come up with customers who would be guaranteed to use such a facility in their projects, but I would be in no way surprised if they end up being easy to find. The industries that we serve are quite likely to have technical needs for message queue solutions. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Raising the minimum to C++20
On Thu, 4 May 2023 at 10:54, Marc Mutz via Development wrote: > > On 04.05.23 00:39, Thiago Macieira wrote: > > And yet, the list of things we want from C++20 is not that big. It's nowhere > > as complex as C++11 and I'd argue that even the 17 upgrade for Qt 6.0 was a > > bigger jump. Unless we add concepts to the list, but I don't think we can > > until we've experimented with it for a while. > > Coroutines will put async APIs upside down. It's a pretty dramatic shift > in how you write async code and Qt as a large provider of async APIs is > going to be strongly affected. Maybe, maybe not. I have written a Qt adaptation for libunifex (i.e. Senders & Receivers), and it coroutineifies every QObject signal generically. If you want to help get that forward (needs some CMake stuff, and tests, examples, and docs), I'll be happy to point you to our internal git repo where that code lives. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Raising the minimum to C++20
On Wed, 3 May 2023 at 03:41, Thiago Macieira wrote: > > C++23 is on the way, so maybe it's time for us to raise our minimum to the one > version before that. Let's aim for Qt 6.7, because feature-freeze for 6.6 is > within one month, and lets us warn our users this is coming. > > By this, I mean to: > * modify our build system so Qt compiles with -std=c++20 or equivalent > * require that user code compiling Qt headers be similarly done > * remove the requirement for #if checks for C++17 Standard Library features > * make a couple of C++20 features mandatory (see below) > > Of the C++20 features I currently see a good reason to make mandatory: > * feature-test macros (no change: we're already using them) > * spaceship operator and header > * char8_t > * std::is_constant_evaluated() > * constinit > * header > * (maybe) designated initialisers > * (maybe) constexpr from and I don't see any of these as worth breaking embedded users who want new Qt versions but don't yet have the compilers that can give them these facilities. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Using '#pragma once' instead of include guards?
On Mon, 10 Oct 2022 at 13:13, Hasselmann Mathias wrote: > > I am surprised by the question: "It's non-standard and it's behavior is > undefined" actually should be enough to avoid such feature. > > Actually if a reliable implementation of "#pragma once" would be > possible, that feature would have been included in the C++ standard for > a long time already, wouldn't it? Oh, there is a reliable implementation, no problem there. :D It's called "hash the file contents". Various implementations have different modes of operation where they desperately try to avoid doing that, or do that just partially. The last time standardizing a "#once" was discussed in the standard committee was 2012, and compiler vendors' feedback killed the idea dead, and it hasn't come back since. We have spent our energy standardizing modules instead. The C committee has been recently considering standardizing a "#once". It has been attempted to make them aware of the compiler vendor feedback on the C++ side of things. It will be a glorious day when we stop doing textual inclusion, and don't need to talk about its myriad problems any more. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Windows maintainer change
On Tue, 15 Jun 2021 at 12:24, Christian Kandeler wrote: > > +1 +1 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Mikko Gronoff as approver
On Mon, 10 May 2021 at 10:10, Samuli Piippo wrote: > > Hi all, > > I'd like to nominate Mikko Gronoff as approver for the Qt Project. > Mikko has been tirelessly working together with the release team to > make sure the embedded releases are always better than the last one. > Although he is not actively contributing to Qt code, having approver rights > would help his work duties and I trust him to use them responsibly. +1 Disclaimer: I'm in the same team as Mikko, but hence I know that this will indeed significantly help his work duties and will help us keep the boot2qt releases rolling, which they do splendidly smoothly and right-on-time. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Moving IRC from Freenode to Libera.Chat, voting thread
On Sat, 22 May 2021 at 04:09, Giuseppe D'Angelo via Development wrote: > > Hi, > > As detailed in the other thread, I'd like to gather lazy consensus for > moving the official IRC presence from Freenode to Libera.Chat. > > Please use this thread for voting ONLY. Apologies for all the formality, > but what I thought should've been a rather painless decision blew out of > proportion. +1 We have already moved the C++ standards committee channels to libera, and there's various other C++-related channels (that are community-operated, not committee operated) that will make the jump. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] User-defined literals for QString (and QByteArray)
On Fri, 5 Mar 2021 at 14:26, Giuseppe D'Angelo via Development wrote: > > Il 05/03/21 12:08, Tor Arne Vestbø ha scritto: > > This seems like a bug though? From an API point of view, I’d expect this > > simple assignment to JustWorkTM, without requiring syntactic sugar all > > over the place. Shouldn’t we fix this, so we don’t need (or leave > > optional) an explicit _qs suffix? > > Because of > >void f(QString); >void f(QStringView); >f(u"foobar"); // ambiguous > > combined with the overarching plan of adding QStringView overloads when > possible (that is, in functions where historically we weren't doing so) > and never breaking BC/SC. Right. Somethings gotta give, and if QString and QStringView are implicitly convertible from the same things, those calls are ambiguous, and there's nothing that can be done about that unless the overload set f decides which one it prefers. Compromising the implicit convertibility would allow us to make one of those functions preferable, but that would mean that all conversions to one of those types need to be explicit. At which point the syntax you want to work doesn't work. The ambiguity doesn't prevent it from working, though - but if we don't want that ambiguity, we need to make either of QString or QStringView not-implicitly-convertible from a literal. Like in this little playground: https://wandbox.org/permlink/mjAdAI56GCjBXhjJ ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QFuture and C++20
On Thu, 4 Mar 2021 at 02:03, Jason H wrote: > > The language parts are there in C++20; what's missing from the standard > > library are "ready-made" coroutines types (task, generator, ...), > > awaitable types, utility functions for scheduling execution, etc. > > > > I've been wondering for a little while how to integrate > > signal/slots/exec()/etc. with coroutines. > > Really glad to hear that you're looking into it! I don't think Qt needs the > ready-made types to target the async stuff? We don't, we can write our own. Some thoughts: 1) if by "exec()" you mean things like QDialog::exec(), the problem there is that It's Already A Coroutine. It's a stackful coroutine. I don't know how to make it both stackful and stackless. Suppose that we change it to return a type that optionally suspends a coroutine. Then we have the following problem: auto&& x = mah_dialog.exec(); some_other_code(); co_await x; There's about a billion things wrong there. The exec() should suspend the fiber, but if it does, it can't be co_awaited later. If it doesn't suspend the fiber, code following it will continue to run, when it might expect exec() to suspend the fiber. I don't know how to hack this into the hypothetical return type of exec(), because the decision to suspend the fiber shouldn't wait until there's an initial_suspend or destruction happening. So that decision would be postponed to be too late, or would happen too early. There's no winning this, so an awaitable exec() needs to be await_exec() or async_exec(), name it what you want, but make it separate. 2) co_awaiting signals shouldn't be too hard. At least in theory, I haven't tried implementing it. You basically make your promise type a slot, and connect it to the signal, and then suspend. And when the slot is called, you resume the coroutine, and suspend again. This seems eminently doable. It does require additional wrapping; you can't just co_await a pointer-to-member-function, you need to wrap it in this promise type and then co_await on that, but that wrapping should be fairly simple, it just needs both the object and the signal. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New features in CI
On Mon, 1 Mar 2021 at 15:31, Lars Knoll wrote: > To fix this, we have now added a new feature (called parallel staging > branches), where CI rounds are not serialised anymore. Instead, COIN will > start a new CI run 15 minutes after a change (or a set of changes) got > staged. It will start that run independently of whether another CI run is > currently happening. If a staging branch passes, all the changes contained in > that branch will be merged into the target branch (can be a fast-forward > merge). If the merge produces a conflict, the staging branch will get > rejected even if it passed CI. > > This means that COIN will usually only test changes that are being staged > together. The advantages are that you can more easily pin down a change that > caused a CI failure, and that your changes will not get rejected because a > buggy change got staged in the same CI run (at least it’s a lot less likely). > > The one drawback is that we can in some rare cases end up with a repository > in a state where two staging branches passed CI and didn’t conflict when > merging them, but the merged state does not pass CI anymore for some reason. > > In that case the branch will be blocked until someone stages a fix for the > problem. But we do expect this to happen rather seldom, so I do believe that > the benefits far outweigh the drawback. > > For now this feature is only enabled in qtbase/dev, but if it works out well, > we will most likely enable it for further repositories and branches. Hallelujah. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The sorry state of the Qt6 cross compile experience
On Wed, 24 Feb 2021 at 12:26, Joerg Bornemann wrote: > > On 2/24/21 9:30 AM, Bogdan Vatra wrote: > > > Do you still believe that I'm one of the few affected by this? > > Don't you think that everyone who's using cross compiling is affected? > > I have seen cross-compiling folks using the cross-platform abilities of > Qt to prototype stuff on desktop. The assumption is: most people want to > have a full desktop Qt anyways. I find that a curious assumption; I've dealt with automotive customers who didn't use a desktop Qt at all, and all they care about was the cross-build for the target. While the assumption might be correct by the head count of users, it may well be a rather bad assumption for some fairly significant audiences. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6 co-installability with Qt 5
On Tue, 16 Feb 2021 at 17:08, André Pönitz wrote: > I agree that update-alternatives is Just Wrong for something that > should effectively be the user's decision (and not even a decision > for all of the user's projects but something that needs to be done > case-by-case). > > On the other hand I don't quite understand all the fuzz about the > Correct Global Name. When I as a user am not happy with someone's > decision on how to name a binary or if a distribution acts funnily or if > I am too lazy to change my muscle memory I set up a shell alias to do > what I want. Well, that sort of thing works great as a local solution, but consider reused scripts, tools, etc. recipes, if you take one of those and run it in your environment, will it do the right thing, the expected thing? Will it do the expected thing if you have both qt 5 and qt 6 on your system? Will it do the expected thing if you have just one of them? Will it do the expected thing if you have just one, and then switch to the other? Therein lies the reason for the fuzz and fuss about the correct global name. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6 co-installability with Qt 5
On Tue, 16 Feb 2021 at 15:35, Kai Köhne wrote: > And again, this is not something limited to Qt. Last time I checked, the > executable to run Python 3 on Windows is python.exe, not python3.exe. On > Debian at least it's python3. This hasn't blocked Python from being perceived > as overall beginner friendly ... Uh.. that seems like an apples-and-oranges comparison. On linux, it's expected and conventional that if you install both python 3 and python 2, both are available in the usual PATH, neither eclipses the other, and you can cd between python 2 and python 3 projects and run both, without switching environments or alternatives in between. On windows, I don't know what's conventional. In many cases, a shortcut is used that launches a command prompt with the right environment, and using two versions in the same command prompt just isn't done. > So, I would stick to qmake as canonical name, also in the documentation. We > can mention that it's sometimes called qmake6 on Linux. But forcing everyone > to change their habit and scripts just for the sake of consistency with a > fraction of the users that use a global installation on Linux, and do not use > update-alternatives, is IMO not a good move. update-alternatives is a long-term system-wide configuration change. Changing PATH is a shorter-term user-specific one. That's how I switch between compilers, and I wouldn't dream of using update-alternatives to switch between them. Especially not on multi-user systems, where it's none of my business to change the alternative used for a system compiler for other people. I *can't* do an update-alternatives on a build server, and I *shouldn't*. That doesn't mean that a build server installation couldn't have both qt 5 and qt 6 installed in a system-wide location. Switching between qt 5 and qt 6 via update-alternatives is Just Wrong. If our approach requires it, our approach is broken. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January
On Wed, 6 Jan 2021 at 09:14, Richard Weickelt wrote: > > > Right. That will become an issue in 4 months when GCC 11 ships with its > > internal > > header-dependency refactorings, breaking all sorts of Qt code, and > > that will then > > bubble down to various distro downstreams during this year and next. Then > > again, > > distro packagers can hopefully handle that. Using the Qt packages or > > installer for 5.15 may > > give you a broken Qt somewhat sooner. Intriguing. > > Could you elaborate? Thanks. These changes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546 cause some amounts of breakage in some Qt headers. I haven't looked at that yet in detail, haven't had time to patch it. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January
On Tue, 5 Jan 2021 at 22:22, Max Paperno wrote: > I'm so sick of "scheduled releases come hell or high water" in the > programming world (in general, not just Qt). The quality is (usually) > crap. Once upon a time this release quality was called > Alpha/Beta/Preview/NFP (not for production). Qt6 has literally been > called as being "primarily" for testing/feedback. That's a new major > release now? /further rant aborted No worries, I for one understand the frustration. I should point out, though, that there are Seriously Bad Examples where programming projects that were expected one day to pay their bills were operating in a "we'll ship it when it's ready", which unfortunately meant that those projects never felt the need to stabilize anything in order to make things shippable. And "it's always ready to ship" is a laughable fairytale. Balancing that is non-trivial. Scheduled releases require rather little extra management, because everybody knows when the release preparation phases begin and what that means. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January
On Tue, 5 Jan 2021 at 21:42, Thiago Macieira wrote: > > 2) support for newer compilers/OS versions/etc. that may cause trouble. > Currently a non-issue, since Qt 5.15 is less than a year old. It may become an > issue in two or three years' time, but hopefully by then the Qt 6.x content > set will meet peoples' requirements. Right. That will become an issue in 4 months when GCC 11 ships with its internal header-dependency refactorings, breaking all sorts of Qt code, and that will then bubble down to various distro downstreams during this year and next. Then again, distro packagers can hopefully handle that. Using the Qt packages or installer for 5.15 may give you a broken Qt somewhat sooner. Intriguing. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What's Q_PRIMITIVE_TYPE for?
On Thu, 12 Nov 2020 at 17:11, Lars Knoll wrote:
> Language Lawyer Hat: is_trivial is the wrong type trait when it comes to
> detect trivial copiability anyhow, example:
>
> struct S { int i; S operator=(const S &)=delete; };
>
> is trivial and not copy assignable. Isn't C++ a fun language to work with...
> :P
>
>
> Sigh… is_trival implies is_trivially_copyable. That one implies
> https://en.cppreference.com/w/cpp/named_req/TriviallyCopyable, which implies
> that all “eligible” copy/move constructor and assignment operators are
> trivial. But they don’t disallow deleting them (as that makes the operator
> not eligible).
>
> So what are the correct traits then? Sounds like “is_trivially_copyable and
> no deleted copy/move operators” is about what we need :/
Well, even libstdc++ uses is_trivial for some memcpy optimizations,
but that chooses strictly fewer types than is_trivially_copyable
would. However, the optimizations I'm talking about are in
std::{uninitialized_,}copy - and there's checks for more than just
is_trivial, because
the really fun part of is_trivial and is_trivially_copyable is that
they tell you whether some sort of memcpy is valid, but that might
not be the kind of memcpy you're doing. Meaning that, when you want to
memcpy over raw storage, you should check
is_trivially_copy_constructible, and if you're memcpying over existing
objects, you should check is_trivially_copy_assignable.
Those traits will check whether the relevant operation is well-formed,
including "not deleted".
Using is_trivially_copy_constructible and is_trivially_copy_assignable
thus also avoids the problem Thiago mentioned, i.e.
UB when skipping a non-trivial or deleted operation. However, in our
code, it's not so simple, because in some cases
we *do* bit-blast non-trivial types, because the standard doesn't
provide relocatability.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QVariant comparison in Qt6
On Tue, 22 Sep 2020 at 17:20, Thiago Macieira wrote:
> And especially if there's no impact to how the user uses the API.
>
> > 1)
> > std::optional compare();
> >
> > 2)
> > enum class Ordering { Less = -1, Equal = 0, Greater = 1, Unordered = 0xff
> > };
> > Ordering compare();
> >
> > 3)
> > Implement a Qt replacement for std::partial_ordering (could use the std
> > stuff if C++ 20 is available) and use that.
>
> I'd rather stay simple and allow extending for where more details
> are necessary.
>
> For that, I think #1.
If this is an API function that users call, make it (2) but make it a
class, not an enum class.
You can then later write a conversion operator that converts the
result to std::partial_ordering.
if this is a private function that no user sees directly, then 1/2 are
both fine. The class I mention
above basically is a Qt replacement for std::partial_ordering, of course.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QVariant comparison in Qt6
On Sun, 20 Sep 2020 at 09:02, Thiago Macieira wrote: > Hmm... I had clearly forgotten about QNX and INTEGRITY, especially the latter. > I thought the problem with QNX was solved since they switched to Clang (or > haven't they?). QNX 7 AFAIK has a compiler based on GCC 8. Switching to Clang doesn't solve this problem; the problem is that such a platform sticks with a particular compiler (major) version for the lifetime of the platform, and during that time, there's now three new C++ standards out. > > Providing optional support for C++20 facilities like spaceship etc. is > > fine. Making significant functionality > > available for C++20 users only, when we don't have to, is not so fine. > > Especially since it's not portable, > > and leads to a splintered Qt, as opposed to a portable Qt. > > How about non-significant functionality? For example, you get operator== and a > compare() function, but if you want the other actual operators, get the > spaceship? Well, that depends on whether the ordering is really insignificant. If it's significant, then we should provide the relational operators even if we can't spaceship them for everybody. If it's just additional icing on the cake and we manage to convince me that the feature is infeasible to maintain unless written in terms of spaceship.. ..maybe. Somehow this smells like "if I can't have my toy with the newest adornments from the shop, I don't want it at all". :) What does is that it provides a wholesale model for comparisons and ties language and library facilities together in a (arguably well-)knit framework, but it doesn't overnight make user-provided comparisons written in the traditional way invalid. Especially if those comparisons are "sane" as expected by the spaceship rules (which are over-draconian, anyway). ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QVariant comparison in Qt6
On Sun, 20 Sep 2020 at 09:06, Thiago Macieira wrote: > > You can't write a conversion from a type you don't own to an int, or > > vice versa. Don't fall into that trap, it's impossible > > to dig yourself out of it. > > Sorry, I don't understand the issue. > > I'm thinking of an internal function that is used to implement operator<=> > (and if pre-C++20 support is desired, operator== and operator<). My bad, I thought we're talking about an API-exposed function. But if that's not the case, then it's even less necessary to bother with conditionally using 's types, and std::optional seems fine. The functionality built on top of it can convert the optional into a weak_ordering, as an optional feature, rather than having the underlying private utility function have multiple definitions or overloads or whatever. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QVariant comparison in Qt6
On Sat, 19 Sep 2020 at 06:28, Thiago Macieira wrote: > But for other things, I'm not shy about it. People can't complain that they > can't use features that didn't exist when they wrote their application. If > they want to use new features, it stands to reason they've just upgraded Qt. > If they can do that, they should be able to upgrade their compiler and > toolchain too. Our customers report otherwise. Upgrading Qt and using it on an older compiler seems doable by a whole lotta customers. Upgrading Qt and upgrading toolchains seems much less doable, so that would be a bold expectation. Toolchains are "deeper" in policy-dictated "infrastructure" than you might think. Try convincing a QNX 7 shop that they have to use a compiler newer than what QNX 7 ships. Try doing the same for some other RTOS toolchains, saying that the platform and the versions they choose are not sufficient, and they need to upgrade to an uncertified experimental version, and they'll walk to our competitors asking whether they're more reasonable about stability and compatibility. Same goes for MSVC and GCC if the shop is large and non-agile enough, and there's no shortage of such shops. Providing optional support for C++20 facilities like spaceship etc. is fine. Making significant functionality available for C++20 users only, when we don't have to, is not so fine. Especially since it's not portable, and leads to a splintered Qt, as opposed to a portable Qt. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QVariant comparison in Qt6
On Fri, 18 Sep 2020 at 21:58, Thiago Macieira wrote: > Anyway, the int suffices because we only need four values: equal/equivalent, > less than, greater than, unordered. We can even adopt the same values: > // less=0xff, equiv=0x00, greater=0x01, unordered=0x02 > or we can use -127 for unordered like libc++ does or -128 like Microsoft STL. Well, if we envision making it convertible to something later on, then *PLEASE* use a class type. I have recent experience on a particular codebase that wanted to migrate from custom allocators to standard allocators, and one significant part of it was converting standard allocators to the custom ones. But that didn't work because the API vocabulary type was CustomAllocator*. You can't write a conversion from a type you don't own to an int, or vice versa. Don't fall into that trap, it's impossible to dig yourself out of it. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QVariant comparison in Qt6
On Fri, 18 Sep 2020 at 18:13, Thiago Macieira wrote: > > On Friday, 18 September 2020 06:48:50 PDT Lars Knoll wrote: > > std::optional QVariant::compare(const QVariant ); > > > > Would that be good enough? > > Why the optional? > > We should use one of the types from [1]. Yes, it's C++20; we can make > our internal API return an integer that is convertible to those types in the > front-end API, under #if __has_include(). > > [1] https://en.cppreference.com/w/cpp/header/compare Why do people keep pushing C++20 facilities when we decided that C++17 is our standard version? How does the int say "I can't compare this"? partial_ordering can do that, but what will the int do? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Important recent changes in QList/QString/QByteArray
On Thu, 10 Sep 2020 at 16:04, Andrei Golubev wrote: > > Should I expect to do a reserve call with a *smaller* value than my > current size is before removing elements from > a container, in order to set a "target size"? For any standard > container, such a reserve is a complete noop because > it can't be responded to by shrinking a capacity lower than the size, > but with QList it apparently records a preferred size? > > No. If the value passed to reserve is smaller than capacity, we do not > shrink*. > For any passed value, we set a specific flag that the capacity is reserved. > There is no notion of "target size" and "target capacity" is out of scope of > the container (this is something that the user knows about). > Instead, having the flag in place, we can decide whether allocation should > take place or not. When allocation is not obligatory and the capacity > reservation flag is set, we do not reallocate but instead do "something > else": in case of erase - just remove elements, in case of prepend - move > data around (if necessary). > The flag is a mere part of QCC's state. The "flag" is basically "a call to reserve was made"? How do I clear the flag? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Important recent changes in QList/QString/QByteArray
On Thu, 10 Sep 2020 at 11:46, Andrei Golubev wrote: > > That's interesting. So the container remembers what sort of a reserve > request I made on it, and uses > that as the preferred size whenever the element count of the container > changes? > > Yes. Calling reserve typically means that you do not want to have extra > reallocations while updating the container's content (instead you allocate > sufficient space upfront). In case of QList, we make sure there are no > reallocations happening unless absolutely necessary, e.g. appending 1 element > when size == capacity would allocate bigger memory chunk - reservation is a > hint, but not an obligation. Consequently, QList's shrinking erase also does > not shrink when capacity is reserved. Well, yeah - calling reserve before growing a container avoids extra allocations. Calling reserve before removing elements doesn't have such a "typical" effect. Should I expect to do a reserve call with a *smaller* value than my current size is before removing elements from a container, in order to set a "target size"? For any standard container, such a reserve is a complete noop because it can't be responded to by shrinking a capacity lower than the size, but with QList it apparently records a preferred size? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Important recent changes in QList/QString/QByteArray
On Wed, 9 Sep 2020 at 16:38, Andrei Golubev wrote: > > I don't understand what this means. Am I supposed to reserve a > container to its current size before erasing elements > from it, if I don't want the erase to shrink it? > > Yes. That's interesting. So the container remembers what sort of a reserve request I made on it, and uses that as the preferred size whenever the element count of the container changes? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Important recent changes in QList/QString/QByteArray
On Wed, 9 Sep 2020 at 11:58, Andrei Golubev wrote: > 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. I don't understand what this means. Am I supposed to reserve a container to its current size before erasing elements from it, if I don't want the erase to shrink it? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Important recent changes in QList/QString/QByteArray
On Wed, 2 Sep 2020 at 17:16, Andrei Golubev wrote: > > 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? > > > Yes, this is what's happening now. But I am considering switching back to > std::vector::erase mode, there's a patch for that already. Let's see how it > goes. After feature freeze? :) ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Important recent changes in QList/QString/QByteArray
On Wed, 2 Sep 2020 at 15:19, Andrei Golubev wrote: > Ville: > > Interesting. I'm curious what sort of repacking happens on erase > > The iterators before or after may be invalidated. Exactly which of the two > (before or after) is going to happen depends on the position of the > to-be-erased range with regards to the position of the full range. I don't quite understand why a vector erase would invalidate vector elements before the erased position. > 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. > > I guess you mean "erase still wouldn't invalidate anything after the erased > position". No. I mean "before", not "after". That's how std::vector works. An erase is a shrinking operation that keeps everything before the erased position untouched and left-shifts everything after it. If you want a prepend optimization, you can get it without changing the way erase works and what the invalidation guarantees of erase are, so I'd like to understand what in our implementation strategy necessitates this change to those guarantees. >But this is effectively undefined (or implementation-specific, as you wish) >and may change in future if we discover a more performing strategy. Again, any >exceptions should be documented. Please do not assume any specific behavior >otherwise. This seems like a potentially quite significant compatibility break, that chopping a vector invalidates all references and iterators to parts of the vector that the chopping didn't touch before. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Important recent changes in QList/QString/QByteArray
On Tue, 1 Sep 2020 at 20:44, Giuseppe D'Angelo via Development wrote: > > 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? 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. ___ 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 Wed, 26 Aug 2020 at 09:39, Lars Knoll wrote:
> > QtGui:
> > * QTextCursor
> > * QTextDocument (find offset, character{At,Count})
> > * QTextLayout
> > * QValidator and subclasses (validate offset)
>
> These here are questionable. Editing a text file with more than 2G
> characters? Sounds unlikely.
Thou Shalt Not Write Debug Log Viewers Or Hex Editors With Qt. :)
___
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 Mon, 24 Aug 2020 at 15:37, Christian Kandeler wrote: > > I don't have verifiable evidence examples, but the gist of it is this: > > > > ConcreteType x = foo(); // this detects API breaks right here, right now > > ... > > ... > > ... > > some_use_of(x); > > > > With AAA, this might become > > > > auto x = foo(); // this always compiles > > ... > > ... > > ... > > some_use_of(x); // you may detect an API break here, or somewhere deep > > inside some_use_of > > > > I wonder where the verifiable evidence is that AAA works at scale. > > What about: > > some_use_of(foo()); > > Are you suggesting that this is an anti-pattern? I fail to see where I might have suggested such a thing. That sort of uses are unaffected by whether an API user does or does not buy into AAA. They certainly are another way to detect (or suffer from) an API break, and trying to use more auto doesn't solve it. ___ 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 Mon, 24 Aug 2020 at 12:17, Mathias Hasselmann wrote: > >> C++ also has a solution for that problem: > >> https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/ > > That non-solution is terrible. The very reason for not using deduced > > types is to detect API breaks loudly. > > The warning does that in dulcet tones, not as loudly as some might > > wish because the conversion is implicit. > > Buying the AAA snake oil can move the problem elsewhere for a while, > > but it's not helpful; it's partially > > hiding an API break, and it's unlikely that you want that to continue; > > the manifestations of the API break > > are going to appear further away from the spots where they could be > > first detected. > > Do you have examples showing verifiable evidence, or do you share a feeling? I don't have verifiable evidence examples, but the gist of it is this: ConcreteType x = foo(); // this detects API breaks right here, right now ... ... ... some_use_of(x); With AAA, this might become auto x = foo(); // this always compiles ... ... ... some_use_of(x); // you may detect an API break here, or somewhere deep inside some_use_of I wonder where the verifiable evidence is that AAA works at scale. ___ 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 Mon, 24 Aug 2020 at 10:50, Mathias Hasselmann wrote: > > Am 24.08.2020 um 09:26 schrieb Giuseppe D'Angelo via Development: > > 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? > > C++ also has a solution for that problem: > https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/ That non-solution is terrible. The very reason for not using deduced types is to detect API breaks loudly. The warning does that in dulcet tones, not as loudly as some might wish because the conversion is implicit. Buying the AAA snake oil can move the problem elsewhere for a while, but it's not helpful; it's partially hiding an API break, and it's unlikely that you want that to continue; the manifestations of the API break are going to appear further away from the spots where they could be first detected. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
On Fri, 24 Jul 2020 at 22:24, Lisandro Damián Nicanor Pérez Meyer wrote: > > A few years ago, Gtk threatened to do that starting with Gtk 4: > > https://lwn.net/Articles/691131/ > > https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/ > > https://blogs.gnome.org/desrt/2016/06/14/gtk-5-0-is-not-gtk-5/ > > > > They changed their minds. > > When those news arose we Qt maintainers felt really really happy that > we maintain Qt, and that's because of BC. > > Qt is already too big to maintain, especially if you are not being > paid for it. Break BC often and finding distro maintainers will be the > hardest thing to do. +1. Frequent BC breaks end up hurting end users, in addition to developers and packagers. They are going to walk, and the developers will follow. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
On Fri, 24 Jul 2020 at 18:10, Thiago Macieira wrote: > Can I suggest that we prepare at least two papers for the standard? One for > the member-to-containing-object trick and the second for what QProperty really > is: sub-scope of a class. We don't want a different this pointer, we just want > to scope. The member-to-containing-object seems like it might just be a fix to what P1839 says. I don't know what the "sub-scope of a class" means. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
On Fri, 24 Jul 2020 at 00:03, Ville Voutilainen wrote: > > On Thu, 23 Jul 2020 at 23:59, Thiago Macieira > wrote: > > > > On Thursday, 23 July 2020 12:34:06 PDT Simon Hausmann wrote: > > > I think the primary environment where a transition and resulting BC > > > breakage would be annoying is the Linux system environment with gcc. This > > > is where Olivier’s solution is quite elegant IMO. > > > > I'd rather go to [[no_unique_address]] instead of this. The extension > > doesn't > > compile in all cases (you can't have a Flexible Array Member everywhere) and > > is going to produce warnings. > > > > Let's just drop GCC 8. > > Does that also drop QNX? It'll also drop mingw for now, unless we start using https://nuwen.net/mingw.html, which is 64-bit only. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
On Thu, 23 Jul 2020 at 23:59, Thiago Macieira wrote: > > On Thursday, 23 July 2020 12:34:06 PDT Simon Hausmann wrote: > > I think the primary environment where a transition and resulting BC > > breakage would be annoying is the Linux system environment with gcc. This > > is where Olivier’s solution is quite elegant IMO. > > I'd rather go to [[no_unique_address]] instead of this. The extension doesn't > compile in all cases (you can't have a Flexible Array Member everywhere) and > is going to produce warnings. > > Let's just drop GCC 8. Does that also drop QNX? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
On Wed, 22 Jul 2020 at 00:18, Volker Hilsheimer wrote: > With the current design, notational convenience doesn’t work either: > > auto text = qAction->text; > text.left(10); // booh > > ‘text’ is not a QString, but a QAction::_qt_property_api_text object, with > broken... everythings. > > > And if people can’t use auto, then you can’t use standard ranged-for to > iterate over container type properties without spelling everyhing out. That’s > ... not convenient, I suppose. And that problem persists, even if we expose a > e.g QProperty reference through a public property member. Couldn't we add operator-> and begin/end to the property type? > The current implementation also adds, in case of us not being able to use > no_unique_address, a byte or even a pointer to each class in a class > hierarchy, bloating classes down in the inheritance tree. Plus the BC > challenge that might come with in the long run. > So, this is not only a problem of UB. There is well defined behavior that > seems to get in the way. Ack. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
On Tue, 21 Jul 2020 at 23:48, Ville Voutilainen wrote: > > On Tue, 21 Jul 2020 at 22:12, Thiago Macieira > wrote: > > > > On Tuesday, 21 July 2020 10:40:27 PDT Ville Voutilainen wrote: > > > A very significant goal of this exercise is achieving notational > > > convenience. Theoretical concerns about UB > > > in the presence of papers that apparently excise that UB shouldn't > > > stand in the way of that goal. > > > > Sorry, I don't agree. We can't use something that is unimplementable. > > Oh, when did that change? Was qobject_cast changed not to be UB? See also all the memcpys that are done with types that are polymorphic, and the ones where we memcpy types that have user-provided copy operations. qtbase is UB left right and center, but it's certainly interesting that when a new thing in it might be clarified not to be UB after all, we perform all kinds of somersaults to avoid such dark corners. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
On Tue, 21 Jul 2020 at 22:12, Thiago Macieira wrote: > > On Tuesday, 21 July 2020 10:40:27 PDT Ville Voutilainen wrote: > > A very significant goal of this exercise is achieving notational > > convenience. Theoretical concerns about UB > > in the presence of papers that apparently excise that UB shouldn't > > stand in the way of that goal. > > Sorry, I don't agree. We can't use something that is unimplementable. Oh, when did that change? Was qobject_cast changed not to be UB? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
On Tue, 21 Jul 2020 at 16:19, Volker Hilsheimer wrote: > object->property = newValue; > > > is not possible with this, but having to write > > object->setProperty(newValue); > > like we do today can’t be a blocker for the entire concept of bindable and > lazily evaluted properties. A very significant goal of this exercise is achieving notational convenience. Theoretical concerns about UB in the presence of papers that apparently excise that UB shouldn't stand in the way of that goal. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
On Mon, 20 Jul 2020 at 19:09, Thiago Macieira wrote: > > On Monday, 20 July 2020 08:40:06 PDT Oswald Buddenhagen wrote: > > On Mon, Jul 20, 2020 at 07:32:41AM -0700, Thiago Macieira wrote: > > >I am not going to accept a null-pointer dereference in there. The > > >static_cast(nullptr)-> must go. > > > > this this construct is actually UB is disputed on wikipedia (in the > > offsetof article). > > There's no dispute. It's a null-pointer dereference, so it's UB. The member-access will not become valid. The only minor dispute is in http://open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#232 but that will not make indirecting through a null pointer like that valid. The only dispute in the offsetof article is about whether that indirection is UB in C. In C++ it is, and will remain so. That's why C++-compliant stddef.h implementations don't do that. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
On Sun, 19 Jul 2020 at 21:52, Thiago Macieira wrote:
>
> On Sunday, 19 July 2020 08:20:01 PDT Thiago Macieira wrote:
> > 1. Revert the feature.
> > 2. Write papers to add necessary functionality to C++23, like reversing a
> >pointer-to-member-object back to the containing object
> > 3. Require C++23 in Qt 7.0
> >
> > double Square::_qt_property_api_width::value() const
> > {
> > return retrieveContainer<::width>(this)->d->width;
> > }
>
> I've dug up my old idea of pointer-to-container. This can be implemented as a
> standard library feature, without a core language change.
>
> Here's a test implementation modernised with C++17 NTTPs:
> https://gcc.godbolt.org/z/GGGE1c
> I *believe* it has no UB but does rely on implementation-defined behaviour of
> a PMO. This IB works for QObject because we don't allow virtual inheritance
> and also because by construction the type is only done on the class that
> introduced the member. A generic solution of PMO reversal requires more work.
>
> In that sense, Peppe's suggestion of C++17 offsetof is better.
>
> The important detail is here:
> static Klass *memberToContainer(Type pmo, ConstMemberType *member)
> {
> quintptr memberAddress = quintptr(member);
> typename QIntegerForSizeof::Signed offset;
> memcpy(, , sizeof(offset));
> quintptr containerAddress = memberAddress - offset;
> return reinterpret_cast(containerAddress);
> }
>
> The memcpy is IB. The containerAddress calculation is the same as in the code
> currently generated by moc, which I initially claimed to be UB, but now I'm
> not sure.
Is there something in it that's UB besides what
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1839r2.pdf
clarifies to become well-defined?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
On Sun, 19 Jul 2020 at 15:25, Oswald Buddenhagen wrote: > (side effects of) actual optimizations are by definition not intentional > belligerence. (one would, however, expect that entire chunks of code > being thrown away would result in a warning that informs about > specifically that (and not just the underlying warning, which may or may > not be enabled).) One could hope so, but expecting that would be foolish. Current optimizers seem to consider warnings to be a job of the front-end, but if the optimizations are value-based rather than symbolic, the front-end can't warn, and then the optimizer won't, and dead code that was considered dead because it has UB will just be axed without warning. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Windows 7 support will be dropped in Qt 6
On Tue, 16 Jun 2020 at 21:04, Matthew Woehlke wrote: > >> Because all KDE applications will have to get ported to Qt 6 soon. > > Why? > ...because if they aren't, they won't get security fixes. (Because Qt 5 > is no longer maintained. Note that "LTS" isn't maintenance for Free > Software, because it won't be available. You'll get 5.15.x releases with a one-year delay from the commercial ones. If you start using it from the first of those releases, and until then, use the previous LTS before that or an earlier Qt version like 5.14, there's very little difference for you. > Also, because if they aren't, the user needs to have two complete > software stacks installed, and those stacks will likely have various > incompatibilities, or at least aesthetic inconsistencies (which are > annoying to users). (This assumes that KDE will even *allow* multiple > versions to be co-installed.) Sure, that's no different from Qt 3->4 or 4->5 transitions. My question "Why?" was mostly about "soon". ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Windows 7 support will be dropped in Qt 6
On Tue, 16 Jun 2020 at 20:27, Kevin Kofler wrote: > > Edward Welbourne wrote: > > Kevin Kofler (16 June 2020 12:08) > >> What "shiny new features"? All that a real-world application such as > >> KWrite really needs from the operating system has been there at least > >> since the 1990s, possibly since the 1970s. > > > > and I guess it's been in Qt for several releases now, so why would > > someone with those needs care about upgrading to Qt 6 ? > > Because all KDE applications will have to get ported to Qt 6 soon. Why? > You seem to be completely disconnected from how things work in the Free > Software community, and only seeing the commercial viewpoint. (Other) Free Software projects occasionally drop old platforms and features more aggressively than Qt does. The C++ compiler you rely on will be out of upstream support in two years, and then you'll need to rely on your distribution vendor to patch it. Earlier versions of Qt are not all that different in this aspect. And new compilers won't run on any old platform you may have. Many libraries won't do that either. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
On Tue, 9 Jun 2020 at 10:35, Ville Voutilainen wrote: > > On Tue, 9 Jun 2020 at 10:29, Shawn Rutledge wrote: > > > > FWIW the configuration mechanism seems a bit less friendly so far with all > > those -DSHOUTED options like -DFEATURE_developer_build=ON instead of > > configure -developer-build. But there is cmake-gui, which generates > > checkboxes for all the options after you have run cmake the first time. > > They are even searchable. Is that a recommended way to discover the > > configure options? (Too bad you have to run cmake twice then.) > > > > There will be no use for running the old configure script anymore then, > > right? > > Last I looked, the configure script can configure a cmake build; it > doesn't support all the options for cmake > that it supports for qmake, but configure -developer-build certainly > worked the last time I checked. I mean configure -cmake -developer-build, of course :P ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
On Tue, 9 Jun 2020 at 10:29, Shawn Rutledge wrote: > > FWIW the configuration mechanism seems a bit less friendly so far with all > those -DSHOUTED options like -DFEATURE_developer_build=ON instead of > configure -developer-build. But there is cmake-gui, which generates > checkboxes for all the options after you have run cmake the first time. They > are even searchable. Is that a recommended way to discover the configure > options? (Too bad you have to run cmake twice then.) > > There will be no use for running the old configure script anymore then, right? Last I looked, the configure script can configure a cmake build; it doesn't support all the options for cmake that it supports for qmake, but configure -developer-build certainly worked the last time I checked. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Drop MSVC 2015 in Qt 5.15?
On Sat, 23 May 2020 at 04:01, Thiago Macieira wrote: > > On Friday, 22 May 2020 02:21:29 PDT Tony Sarajärvi wrote: > > Hi > > > > Now open for discussion: https://bugreports.qt.io/browse/QTQAINFRA-3745 > > > > Based on Thiago’s comment that we don’t want to keep supporting it for > > years: > > https://codereview.qt-project.org/c/qt/qtdoc/+/269546 > > My opinion is clear. +1 Kill it with fire. +1 ___ 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 Fri, 22 May 2020 at 20:43, Jason H wrote: > > How about I just pay - which my company already does? The lagging mobile > support has us considering moving away from Qt. I think this decision would > confirm our direction and only hasten our departure from the Qt ecosystem. Please tell me where your multimedia(1) (or general mobile(2)) bug reports are, I get pizza for fixing them on a bug-fixing week. :) Jokes aside, I don't know who pays for what, but there are technical ways to convince at least tech management that multimedia as a built-in component is an.. ..essential thing to have. Whether that convinces the biz management, I don't know, that's not my cup of tea. I might make the bold assessment that we're not entirely aware of how many users rely on QTMM and for what, and I might make a bold prediction that having a better handle on that might lead to beneficial for those to whom it is an important piece of functionality. (1) I can ask Val nicely to fix them. (2) I can ask Assam and Tor Arne and others to fix these, or I can fix them myself. These don't even require a bug-fixing week to have attention given to them. ___ 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 Fri, 22 May 2020 at 17:19, Jason H wrote: > I object, and wish multimedia to remain an essential part of Qt. Then help maintain and develop it. Wishes are cheap. ___ 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 Tue, 19 May 2020 at 16:02, Val Doroshchuk wrote: > > Hi all, > Just small update that Qt Multimedia is going to be moved from essentials > modules to Add-On on Marketplace for Qt 6. > More information will be announced a bit later. With what license? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Untangling our platform plugins
On Fri, 15 May 2020 at 13:45, Lars Knoll wrote: > > Thanks for writing this up Tor Arne. +1 for the general plan from my side. +1 good plan. I have recently been scratching my head about where platform-specific qtbase utilities should go, like facilities to convert Qt containers into Java Arrays for Android JNI usage, and extras didn't seem like a good place because a qtbase plugin would need to use it, and some extras bits might also want to use it, and so on. Just putting it next to our cross-platform code as a platform-specific extension/addendum/extra would make this much more straightforward. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QString and related changes for Qt 6
On Wed, 13 May 2020 at 12:50, Tor Arne Vestbø wrote: > > > > > On 13 May 2020, at 10:12, Edward Welbourne wrote: > > > >> 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). > > > > Would it suffice to skip the QString(char16_t *) constructor and, > > instead, have a QString(QStringView) constructor ? > > > > I guess calls to functions taking QString would have to make one of the > > steps explicit, when passing a u"...", i.e. either call > > f(QString(u"...")) or f(QStringView(u"...")), preferring the latter (as > > it's future-proof against f changing signature from QString to > > QStingView later; note that this concern applies to Qt-using code, which > > may allow itself such ABI-breaks, not just Qt itself, which wouldn't, at > > least not once the old API has appeared in a public release). I suppose > > both forms are capable of exploiting constexpr and happening at > > compile-time, when the compiler deigns to make it so. > > Whatever we end up with, _please_ avoid the > explicitness/verboseness/boilerplate of having to wrap every “foo” in some > QPreferredStringTypeOfTheWeek(“foo”) > > I expect my code to looks like this: > > foo.bar(“baz”) > > Or if the allocations and conversations are really a performance issue for > this particular piece of code: > > foo.bar(u“baz”) > > Anything else should be reserved for corner cases where the explicitness is > warranted. That's all well and good, but if foo.bar(a) and foo.bar(b) have different semantics on whether the class copies or views what I pass in, I am going to hurt you. :) Meaning that if it sometimes stores a copy, then it should always store a copy, instead of sometimes storing a copy and sometimes storing a view, in which case I need to be insanely careful about calling such functionality. If the class doesn't store the argument, I don't care. If it does, it should decide whether it stores a copy or a view. Overloads in an overload set should have the same semantics, otherwise that API is a vector, where for some incoming types it does A and for others it does B, and the code can no longer be read without looking at the API documentation for every call. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Views in APIs
On Wed, 13 May 2020 at 12:46, Marc Mutz via Development wrote: > In the not so hypothetical case that Qt is used to visualize results of > some business calculations, chances are that thrid-party libraries will > use std::string or std::u16string, and not QString, requiring the use of > QString::fromStdString() to pass these to a QString API. Had the API > taken QStringView, no extra code would have been necessary. Wait, what? How can QStringView view a std::string? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Views in APIs (was: Re: QString and related changes for Qt 6)
On Wed, 13 May 2020 at 12:37, Marco Bubke wrote:
> auto view3 = myObject.getCopy()[42].getView(); // not safe, copy is destroyed
> AFAIK you can say that a rvalue should not return a reference by using
> ref-qualified member functions.
> View getView() const & { return v;}
However,
whatever_function(myObject.getCopy()[42].getView()); // never dangles,
so always safe
Disabling reference returns for rvalues prevents such forwarding cases
from working, and you need
to declare a separate lvalue to make your code work.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] [SPAM] How bad QList really is
On Sat, 25 Apr 2020 at 17:45, André Pönitz wrote: > What I see here is a general-purpose random-access container with cheaper > insertion and deletion at front and in the middle than *vector provides for > 61.3% of the types, augmented by a small-object optimization that kicks in > with zero overhead for 98.5% of the actually created instances. > > If such a container did not exist it would need to be invented. I wonder, to what extent those properties apply to the proposal for std::colony, here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0447r10.html std::colony doesn't have random access, but it's somewhat telling that there are attempts to add a standard container that otherwise fills somewhat similar sweet spot niches (that might not be small niches) as Qt5's QList does. The purposes and goals are a tad different from Qt5's QList, but they certainly reveal another perspective according to which vectors and lists and maps don't necessarily cover all reasonable uses. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [SPAM] How bad QList really is
On Tue, 28 Apr 2020 at 10:59, Giuseppe D'Angelo via Development wrote: > > What I see here is a general-purpose random-access container with cheaper > > insertion and deletion at front and in the middle than *vector provides for > > 61.3% of the types, > > 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. > > > Thanks for the scientific approach, Here's what I'm curious about. With Qt5 and QList, and with Qt6-like "QList is QVector", if we run the scenario André depicted and measure wall clock time, which one wins? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: Deprecate QVector in Qt 6
On Mon, 27 Apr 2020 at 10:10, Alberto Mardegan wrote: > > On 23/04/20 14:57, Ville Voutilainen wrote: > > QVector is certainly closer to std::vector than QList is to std::list. > > Vector isn't a really good name either, > > for people recently taught in elementary school math, or for java > > programmers coming in. > > For C++ programmers, it gives a much better suggestion of what it is > > than calling it QList does. > > This calls for a nice QArray type :-) Arrays don't expand. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: Deprecate QVector in Qt 6
On Fri, 24 Apr 2020 at 13:58, Edward Welbourne wrote: > > Giuseppe D'Angelo (24 April 2020 10:19) asked > >>> Which "one year release approach" are we talking about here? > > On 4/24/20 12:36 PM, Edward Welbourne wrote: > >> That would be Vitaly's proposal to have major releases yearly. > > Giuseppe D'Angelo (April 24, 2020 12:38) > > 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? > > Vitaly favours getting rid of QList in Qt6 and providing tools to > automate conversion. Some of us will only consider this a credible > option when we see those tools in operation. Quite how the faster major > release cycle would bear on this, I must leave Vitaly to answer. Unless there are conversion tools that can convert back and forth, this approach will never work. The fairytale of automatic conversion that is usually spun fails to even consider this, and it tends to be so that even the half-assed half of the conversion fails to materialize, let alone the other half that is an absolute must for such a conversion to be a feasible solution to migration over an API break. Otherwise the maintenance cost of targeting two incompatible sides of the API fence is still doubled. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: Deprecate QVector in Qt 6
On Fri, 24 Apr 2020 at 13:38, Edward Welbourne wrote: > > On 4/23/20 11:10 PM, Vitaly Fanaskov wrote: > >> Moving to one year release approach doesn't equal to make Qt less stable. > > Ville: > > Of course it does, if we now allow API breaks every year. > > Not necessarily: if we *allow* API breaks every year *but* are > restrained in our use of them - so that, in fact, over a given ten year > period, we only make as many API breaks; we just spread them out over > time more evenly - then we'd be no less stable; and it'd be easier for > client code maintainers to keep up with our major version updates, > because they'd be smaller. That is still less stable. The more frequent the API breaks are, the less stable the API is. The size of the API break matters as well, but that's easier to control; I make the decision whether to jump now or later, and the size of the break to a large extent affects what the schedule of the jump is, not that much whether to take a jump (unless it's so large as to be over the breaking point, of course). If I'd need to consider such a jump every year, I'd switch to something else, including changing the programming language if need be. Annual API breaks are untenable for any product that has a limited budget. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: Deprecate QVector in Qt 6
On Fri, 24 Apr 2020 at 00:13, 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. Of course it does, if we now allow API breaks every year. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: Deprecate QVector in Qt 6
On Thu, 23 Apr 2020 at 14:28, André Pönitz wrote:
>
> On Thu, Apr 23, 2020 at 12:30:32PM +0300, Ville Voutilainen wrote:
> > On Thu, 23 Apr 2020 at 12:25, Philippe wrote:
> > >
> > > Almost all the time I second your positions, but not this time ;)
> > >
> > > QList is historically a cause of ambiguity, and Qt6 is the chance to get
> > > rid of that.
> >
> > Indeed. QList causes confusion for the uninitiated that are aware of
> > the differences between std::vector and std::list [...]
>
> And "vector" confuses the uninitiated who expect it to be an element
> of a vector space, to point somewhere, to carry diseases, or to be
> something like a single pointer ("interrupt vector").
>
> I really wonder who thought that "vector" was a good name for a
> container of not necessarily scalar elements that can change its
> dimension.
>
> Maybe someone who was involved with the initial choice of that name
> can share some insight?
Stepanov chose the name; that much we know. Some ruminations, accuracy
unknown. I can't find
any material on it in the newer TC++PL edition I have:
https://stackoverflow.com/questions/581426/why-is-a-c-vector-called-a-vector
QVector is certainly closer to std::vector than QList is to std::list.
Vector isn't a really good name either,
for people recently taught in elementary school math, or for java
programmers coming in.
For C++ programmers, it gives a much better suggestion of what it is
than calling it QList does.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: Deprecate QVector in Qt 6
On Thu, 23 Apr 2020 at 12:25, Philippe wrote: > > Almost all the time I second your positions, but not this time ;) > > QList is historically a cause of ambiguity, and Qt6 is the chance to get rid > of that. Indeed. QList causes confusion for the uninitiated that are aware of the differences between std::vector and std::list (as in Why Do These People Use Lists Everywhere? Why don't they use Vectors?). Now we have papered over the problem, but the name remains problematic, because QList is not a list. In Qt5, QList is sometimes a list, sometimes a vector, but in Qt6 it's never a list. Switching the QVector implementation over to a type called QList and aliasing QVector to that with the intent of getting rid of the QVector name seems exactly backwards to me. I would think the better approach would be to keep dev as it is, and deprecate and eventually remove QList. ___ 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
On Tue, 14 Apr 2020 at 11:22, Nathan Myers wrote: > Neither does Ville have authority to speak on behalf of > the Library Evolution Working Group. The slight difference, of course, is that I enumerated bits of rationale that were actually uttered in that discussion, rather than colorful suggestions of how the majority of LEWG must think that widespread abuse of a variant of cocaine is the sole reason why such a proposal even came to their plate. > The WG was firm but polite, this once. Expect greater > firmness, and less politeness, next time. Take the hint. Now, that *is* an invitation to dance. :D I shall, however, mostly pass the opportunity. In case you wish to ask me what hints I will and will not consider when evaluating whether to propose some hypothetical thing to the committee, feel free to ask for elaboration privately. > Asking the ISO WG21 C++ Standard committee to compensate > for one library's extended process failure is, at best, > rude and foolish. There's nothing rude in providing information that the committee may not have been aware of about compatibility issues with new standards. ___ 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
On Tue, 14 Apr 2020 at 12:31, Lars Knoll wrote: > What kind of argument is that? htons as a macro was worth considering, but > the ones in Qt are not? > > Fixing the htons macro also "only requires changing one place" in the System > C library. You are forgetting, that both changes break a huge amount of user > code out there. And Qt’s macros have been around for about just as long (25 > years), so they also *long* precede the existence of ISO WG21. Well, there are multiple C libraries. So it was never just one place for that particular problem. However, we should recognize that "could have been as easily fixed on any day of the past 20+ years" applies 100% as well to those macros. ___ 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
On Mon, 13 Apr 2020 at 06:11, Nathan Myers wrote: > The prevailing feeling in the room, when the vote was taken, > was that Qt people MUST BE SMOKING CRACK if they think > the ISO 14882 C++ Standard should or would tiptoe around Qt's > aggressive abuse of lower-case macro names. That Qt has abused > them for a long time makes the abuse exactly that much *less* > excusable. To wit: you cannot claim you didn't know better. While the argument was indeed made that the prolonged time we have had lower-case macros in our public API makes accommodating them less appealing for WG21, the 'prevailing feeling' is something where you speak on behalf of a working group without the authority to do so, and it's highly questionable whether that feeling was as prevailing as you suggest. It also doesn't require smoking crack to suggest that WG21 considers code breakage due to new identifiers clashing with existing macros; they've done so before, when the Networking TS and its functions with names like ntohs and htons clashed with macros. > It would not be at all surprising if uses of all the other > abused names--signals, slots, etc--show up in key components > of C++23. Asking the committee to change them could not > reasonably be expected to produce a peaceful outcome. The outcome of this last asking was plenty peaceful. > Marc's proposal is far too modest. Just change the default, > in a single step: eliminate the abusive macros, as any > responsible organization would have done *decades* ago. > (An accompanying apology for past abuse would not be out of > place.) Anybody who wants to keep using the abusive macros > already knows how. They will also know that they are > deliberately choosing to do The Wrong Thing. Why? The users of emit don't care it's a macro, and if they never use osyncstream, they don't run into this problem. Forcibly breaking their code without any sort of soft migration path doesn't seem like a user-friendly way to approach it. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Nominating Assam Boudjelthia as Approver
Patches here: https://codereview.qt-project.org/q/owner:assam.boudjelthia%2540qt.io Assam has been doing great work on Android, qemu, boot2qt, and a whole bunch of things. If things go as planned, he will be our Android maintainer. ___ 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
On Fri, 28 Feb 2020 at 22:35, Lars Knoll wrote: > >> You'd see instead: > >>this->emptied().emit(...); > >>connect(foo, foo->emptied(), ...); > > I like this, then we could finally (and without hacks) have protected and > > private signals like in Qt 4. > > Would also solve the need for qOverload ? > This is all nice and fun to bike shed about, but I don’t think those proposed > solutions match the scope of the original problem (which was relatively > small). I don’t think a massive source compatibility breakage is what we > want, just because there is one std header using emit as a method name. > > And most of Qt’s signals are named in a way that makes it rather obvious it’s > a signal we’re looking at (e.g. fooChanged() or clicked()), so there’s no > need for an ‘emit’ in front to be clear. Some names are less obvious and the > ‘emit’ does help readability of our source code. > > So to shortcut this discussion a bit: I am completely opposed to a massive > SIC changes/efforts for our signals (like giving them ugly names like > emitClicked(), or signal objects). Just turning signals into objects seems SC to me. But nothing will be SC if it has the whole-token "emit" in it. So if we want to introduce some sort of a more-structured C++ approach, we need to pick a different name for it to coexist with emit. > If people feel strongly, I am open to trying to find a way to keep some sort > of ‘emit’ prefix (whether that’s Q_EMIT or a [[qt::emit]] attribute), but I > do agree with Marc that we should in the long term try to get away from > having emit/signals/slots defined as macros (at least by default). Agreed. ___ 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
On Thu, 27 Feb 2020 at 09:15, Alex Blasche wrote: > >In general, implementations can still warn about pretty much whatever > >they please, especially considering > >that their default modes are not strictly conforming. > > > >The compilers we plan to support in Qt 6 do warn about unknown > >attributes, so the allowance point is kinda > >theoretical. > > Ville, please help me understand sth. If the express intention of attributes > is that users should be encouraged to have their own, aren't the warning > policies exhibited by current compilers counter productive to the intent of > their intended purpose? Or do attributes mostly exist for the purposes > compilers themselves may face? They are counter-productive, yes. The compilers overreach, see below. > Also what's the chance that compiler communities might accept Qt specific > attributes if for example TQtC were to put relevant patches forward? The chance is very good; I talked about this with the maintainer of GCC already, and he was amenable to disabling an "unknown attribute" warning if the attribute has a namespace. For attributes that don't have namespaces, diagnosing unknown attributes allows diagnosing typos, so it's unlikely that all such warnings would be axed. I may need to write that patch myself. In any case, such solutions don't help GCC 9.x users or users of earlier GCC 10.x versions, in case the patch wouldn't hit GCC 10. I think the chance of success is similarly good with clang; the case for not complaining about namespaced attributes is fairly clear. But that change isn't something I have time to patch into clang. I haven't looked at MSVC or other compilers. ___ 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
On Wed, 26 Feb 2020 at 18:45, Benjamin TERRIER wrote: > I would like the idea of using attributes for this. However, compilers are > allowed to warn for unknown attributes, which is useful to detect typos. > This means that we would get a warning for each usage of [[qt::emit]]. So > unless there is a way to disable unknown attribute warnings for a specific > set of custom attributes this will be a pain. That's debatable. [dcl.attr]/6 says Any attribute-token that is not recognized by the implementation is ignored. In general, implementations can still warn about pretty much whatever they please, especially considering that their default modes are not strictly conforming. The compilers we plan to support in Qt 6 do warn about unknown attributes, so the allowance point is kinda theoretical. ___ 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
On Wed, 26 Feb 2020 at 14:44, Tor Arne Vestbø wrote: > > We’re neither enforcing the use of ‘emit’ currently. And I honestly find > > most of the alternatives to be worse than no annotation at all. > > I agree. > > As others have argued, a signal is not special, in the sense that any > function can do anything, including emitting signals, so annotating it > doesn’t seem critical, as we apparently are fine without in all other cases. Yep, this part of it destroys the "annotate the yield operations" for me; if I call another function that then signals, I don't see the annotation, so the warm and fuzzy feeling of safety requires a very particular programming style. ___ 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
On Tue, 25 Feb 2020 at 10:19, Ville Voutilainen
wrote:
> Or perhaps qEmit(this)->my_signal(Args...);
>
> and hide the befriending of qEmit (so that private/protected don't
This doesn't even need friending.
#include
template
struct qEmit
{
T* that;
qEmit(T* it) : that(it) {}
T* operator->() {return that;}
};
struct X
{
void sig1() {std::cout << "sig1\n";}
void sig2() {std::cout << "sig2\n";}
void foo() {
qEmit(this)->sig1();
qEmit(this)->sig2();
}
};
int main()
{
X x;
x.foo();
}
___
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
On Tue, 25 Feb 2020 at 22:17, Matthew Woehlke wrote: > Right, and when I realized that, it got me wondering, how many people > will need to call that specific function that are *also* using Qt *and* > will be unwilling to use Q_NO_KEYWORDS to work around the issue? You're getting back to the reason why renaming osyncstream::emit() was unconvincing, here. ;) But the reason why we are talking about this is to search for a solution where such clashes don't happen in the future. Yes, we know how to deal with boost::signals, yes, we know how to deal with X11 Status clashing with QSettings::Status, but maybe we shouldn't have to deal with these clashes that are our own doing because it's us defining the problematic macros. (In the X11 case, it's X11, not us.) We could be better-behaving citizens of the ecosystem, instead of saying "well we've been bad citizens for a long time, please just accommodate us, here's hacks that allow you to circumvent the problems we cause". ___ 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
On Tue, 25 Feb 2020 at 21:37, Matthew Woehlke wrote: > > On 24/02/2020 07.34, Edward Welbourne wrote: > > Mitch Curtis (24 February 2020 13:22) > >> I don't think anyone has explained what that harm is yet. > > > > #define emit > > > > causes problems when you import a header that declares > > > > void emit(Type arg); > > > > and the compiler sees > > > > void (Type arg); > > > > and throws a wobbly. > > - Until now, `emit` has rarely been used in code that needs to mix with Qt. > > - C++20 will have modules. > > - Modules are theoretically immune to the above issue. Module definitions are immune to macros affecting what they export, but client code is not immune to mixtures of module imports and header includes when the latter defines a macro. If you import a Std.IOStream module and then include QObject, you can't call std::osyncstream::emit(). > Where, exactly, is the problem? It seems to me we are making a big deal > out of something that will *still* only be a problem when mixing Qt > (with no QT_NO_KEYWORDS) and *certain uses* of . Correct. > This doesn't seem appreciably different from the existing situation with > boost::signals. Ergo, I am confused why we are all acting like the sky > is falling? Indeed. > Maybe we should, at least, take a step back and wait to see if this > *actually affects many people* before worrying about it? Seems reasonable. ___ 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
On Tue, 25 Feb 2020 at 00:30, Marc Mutz via Development wrote: > Qt relies on macros a lot, and while I have not followed the latest > Modules development, I'm sure macros pose a problem for a modularized > Qt, too. Header units can still export macros. Macros don't go into header units or named modules from the client, but that doesn't save the situation - if you import osyncstream and #define emit (via whatever means), you still can't call osynctream::emit. So for modules, the clashes are not as likely, but they aren't completely unavoidable as long as emit is a macro. > Can access specifiers have attributes? > public [[qt::slots]]: > That is pretty much exactly how the 'metaclass' (really just reflection+injection, with the reflection+injection metaprograms called from the class definition body, because that's where Q_OBJECT resides) approach envisions doing slots; there was an idea floated around that you could write public: ... current [[qt::slots]]: ... current: so that 'current' is just 'public', or actually whatever was the access at that point. Then 'slots/Q_SLOTS' can expand into 'current [[qt::slots]]:' and the meta-transformation can generate the code moc would generate today. ___ 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
On Mon, 24 Feb 2020 at 17:17, Allan Sandfeld Jensen wrote: > Yeah you would need something like qEmit(_signal, Args..) or without & > using a macro. Or.. qEmit(std::bind(_signal, Args...)); Or perhaps qEmit(this)->my_signal(Args...); and hide the befriending of qEmit (so that private/protected don't thwart this) inside Q_OBJECT. ___ 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
On Mon, 24 Feb 2020 at 15:52, Ville Voutilainen wrote: > > On Mon, 24 Feb 2020 at 14:42, Lars Knoll wrote: > > But we could convey the information that this is a signal you’re calling > > *reliably* through other means. This implies that the keyword is not > > required. > > Was the keyword ever required? Seems like it's just a taste difference from a > > qEmit(my_signal()); > > to write > > emit my_signal(); > > The first one can be namespaced, and thus its name lookup controlled. > It also never clashes with a member name. > Its worse aesthetics aside, if we'd had that since the beginning, we > wouldn't be talking about the current clashes > with std::osyncstream. Hah, except it of course doesn't work with my_signal that returns void. ___ 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
On Mon, 24 Feb 2020 at 14:42, Lars Knoll wrote: > But we could convey the information that this is a signal you’re calling > *reliably* through other means. This implies that the keyword is not required. Was the keyword ever required? Seems like it's just a taste difference from a qEmit(my_signal()); to write emit my_signal(); The first one can be namespaced, and thus its name lookup controlled. It also never clashes with a member name. Its worse aesthetics aside, if we'd had that since the beginning, we wouldn't be talking about the current clashes with std::osyncstream. ___ 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
On Mon, 24 Feb 2020 at 14:35, Mitch Curtis wrote: > > > > > Signals have different semantics than regular functions. > > > > > > > > In what way? > > > > > > They typically call back into "upper layers", which is worth considering > > > on > > the calling side, e.g. due to the danger of inconsistent state getting > > accessed > > if you don't emit the signal at the end of a function, to name just one > > tyical > > pitfall. > > > I, for one, definitely want to see whether I am emitting a signal or not. > > > > Right; the claims that you can ignore signal emits when looking at a piece > > of > > code or expect that they don't affect the current scope are exactly > > backwards. > > > > A signal emitted yields to a coroutine scheduler that runs arbitrary > > callbacks, > > which in case of direct connections absolutely can affect the current scope. > > > > Thanks, Christian - that's the first ever plausible explanation for marking > > a > > signal emission. > > Personally I find it a bit concerning that you don't consider readability or > maintainability a plausible explanation for annotating code with emit. I find it rather more concerning that you make such a claim, when in the quoted bit I do consider readability and maintainability such plausible explanations. Perhaps that's because I don't consider vague claims of readability and maintainability plausible, but I do consider readability and maintainability with an actual reason plausible, and typically-calling-up-into-arbitrary-code-that-can-and-does-call-back-to-us is such a reason. >Though I can rest easy with the knowledge that you're not the sole authority >for what constitutes a plausible explanation, despite how you worded it. Well, for what constitutes a plausible explanation to me, I actually am the sole authority. > I can only assume that that same mindset must also encapsulate all of the > developers who never wrote any comments for their code because... it made > sense to them and that's all matters. Did you plan to set that strawman on fire, or are you just playing with it? ___ 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
On Mon, 24 Feb 2020 at 11:23, Jean-Michaël Celerier wrote: > > A good inspiration for that feature would be the Just My Code feature of > recent visual studio : > https://docs.microsoft.com/en-us/visualstudio/debugger/just-my-code?view=vs-2019 That is indeed what I'm gunning for. :) If our problem is that users mistakenly step into moc-generated code, let's fix that in our tooling instead of inventing new language keywords. ___ 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
On Sat, 22 Feb 2020 at 13:07, André Pönitz wrote: > > Buy a debugger that can skip code that you didn't write. > > The point was that in a such a situation I, as user, would not even > try to step in when the call is marked with 'emit'. This 'emit' in > a line *is* valuable markup, that saves me time. > > That's unrelated to what the debugger would or could do if I did step in, > I just don't need to follow that path. > > [And apart from that: There's no need to *buy* such debugger, e.g. gdb's > 'skip' actually works] It occurs to me that, in case Creator doesn't do that already, we could make its debugger UI to automatically tell the underlying debugger to skip moc-generated code, as a default. > > The committee shot down the proposal because > > 1) there are work-arounds to the problem, and we already use those > > work-arounds for similar > > issues with boost::signal > > 2) trying to avoid clashes with lowercase non-function-like macros is > > rather difficult > > 3) the scope of the problem is narrow > > 4) no existing code is broken > > Is that documented, perhaps with a bit more detail, somewhere? Not that I know of - the LWG issue hasn't been updated yet. Is there some particular detail that you're missing? ___ 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
On Fri, 21 Feb 2020 at 22:11, André Pönitz wrote: > > On Fri, Feb 21, 2020 at 04:02:04PM +0200, Ville Voutilainen wrote: > > > I, for one, definitely want to see whether I am emitting a signal or not. > > > > Right; the claims that you can ignore signal emits when looking at a > > piece of code or expect that they > > don't affect the current scope are exactly backwards. > > Christian is right and your conclusion is wrong. My conclusion is fine. Your unsubstantiated claims don't make it wrong. > See the already mentioned example of debugging in code that follows > the convention of using signals only for inside-out communication: Buy a debugger that can skip code that you didn't write. > Emitting the signal may cause all kind of activity on the outside, > but in first approximation one can assume it doesn't change state in > the current object. So when drilling down in this situation > "ignoring" emit is indeed natural. Seems quite unnatural to me, considering that signal emissions reasonably often tend to result in further calls being made to the object. > > Thanks, Christian - that's the first ever plausible explanation for > > marking a signal emission. > This sounds a bit like the committee shot down the proposal to > not use 'emit' without even bothering to think about reasons why > there are users of this "nonsense", let alone tried to ask them. The committee shot down the proposal because 1) there are work-arounds to the problem, and we already use those work-arounds for similar issues with boost::signal 2) trying to avoid clashes with lowercase non-function-like macros is rather difficult 3) the scope of the problem is narrow 4) no existing code is broken ___ 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
On Fri, 21 Feb 2020 at 15:44, Christian Kandeler wrote: > > On Fri, 21 Feb 2020 15:00:53 +0200 > Ville Voutilainen wrote: > > > On Fri, 21 Feb 2020 at 14:58, Sérgio Martins > > wrote: > > > > Why do I need to know that it's a signal being emitted? How is that > > > > "vital information"? I could just as well > > > > invoke any other callback, but I find myself not exactly yearning for > > > > being able to write > > > > callback somethingHappened(); > > > > > > > > > Signals have different semantics than regular functions. > > > > In what way? > > They typically call back into "upper layers", which is worth considering on > the calling side, e.g. due to the danger of inconsistent state getting > accessed if you don't emit the signal at the end of a function, to name just > one tyical pitfall. > I, for one, definitely want to see whether I am emitting a signal or not. Right; the claims that you can ignore signal emits when looking at a piece of code or expect that they don't affect the current scope are exactly backwards. A signal emitted yields to a coroutine scheduler that runs arbitrary callbacks, which in case of direct connections absolutely can affect the current scope. Thanks, Christian - that's the first ever plausible explanation for marking a signal emission. Getting back to macro vs. function.. I think using a function wrapper is fine, considering that signals can't meaningfully return, so the prvalue/xvalue issue doesn't arise. We could even have qEmit() return void, to prevent a possible return value from being (ab)used. Yeah, I'm sure we'll have no trouble finding people who think qEmit(mah_bucket_callback()); is unacceptably ugly compared to qEmit mah_bucket_callback(); The big advantage of that ugly version is that it's regular C++ without using macros. At the risk of riffing on this a tad too far, we could alternatively consider using an operator on a global dummy qEmit object, but that runs a risk of getting into precedence games. ___ 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
On Fri, 21 Feb 2020 at 15:00, Ville Voutilainen wrote: > > And I'd argue that the emitter shouldn't even know who or how many slots > > are connected to the signal, might even be zero, it shouldn't matter. > > ..and? What does that have to do with whether you do or do you emit? Mr. Email Client, stop autocorrecting me incorrectly. "..whether you do or don't use emit". ___ 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
On Fri, 21 Feb 2020 at 14:58, Sérgio Martins wrote: > > Why do I need to know that it's a signal being emitted? How is that > > "vital information"? I could just as well > > invoke any other callback, but I find myself not exactly yearning for > > being able to write > > callback somethingHappened(); > > > Signals have different semantics than regular functions. In what way? > If I'm reading the body of makePlane() I can ignore the signal > emissions, as they aren't important for how a plane is made, they just > inform whoever is listening. That doesn't seem to be correct in general. Some signals absolutely must be emitted for clients to work correctly. > And I'd argue that the emitter shouldn't even know who or how many slots > are connected to the signal, might even be zero, it shouldn't matter. ..and? What does that have to do with whether you do or do you emit? ___ 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
On Fri, 21 Feb 2020 at 14:57, Mitch Curtis wrote: > > It’s not beter than any code comment that you could also put there, like > > > > /*emit*/ something(); > > > > or > > > > something(); // emit > > I disagree; I think those are ugly. Having a keyword-extension to normal C++ is ugly as sin, to some of us. It causes fair amounts of "wtf is that?". ___ 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
On Fri, 21 Feb 2020 at 14:21, Ville Voutilainen
wrote:
>
> On Fri, 21 Feb 2020 at 14:00, Allan Sandfeld Jensen wrote:
> > Hmm.. Or perhaps:
> >
> > #define qEmit(x) x
> > or
> > #define qEmit(x) do { x; } while (false)
> > to handle the syntactic edge cases.
>
> Well, if we're re-entertaining a function-like wrapper, we could just
> as well avoid
> getting back to the not-so-wonderful world of macros, and do
> template T&& qEmit(T&& t) {return std::forward(t);}
..but this doesn't really work, because it turns prvalues into
xvalues, and thwarts lifetime extension of reference
to prvalues, so scratch that idea.
___
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
On Fri, 21 Feb 2020 at 14:30, Mitch Curtis wrote: > > > 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? > How can you tell if it's a signal being emitted or just a function call > without the emit syntax? With the emit syntax before the signal emission, > it's immediately obvious that it's a signal. Not all signals follow the > *Changed() naming convention, nor should they, so it becomes even less > obvious in those cases. Why do I need to know that it's a signal being emitted? How is that "vital information"? I could just as well invoke any other callback, but I find myself not exactly yearning for being able to write callback somethingHappened(); ___ 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
On Fri, 21 Feb 2020 at 13:52, Julien Cugnière wrote: > > Le ven. 21 févr. 2020 à 12:29, Giuseppe D'Angelo via Development > a écrit : > > > > 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. > > 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. Indeed. I'm still waiting for an explanation for the need for emit. I am trying as hard as I can to spot such a need, and failing. The apparent need is riding on a hypothesis that signals are special, but they aren't. They are just like all other functions, albeit generated functions, but in that sense no different from other functions that you didn't write. ___ 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
On Fri, 21 Feb 2020 at 14:00, Allan Sandfeld Jensen wrote:
> Hmm.. Or perhaps:
>
> #define qEmit(x) x
> or
> #define qEmit(x) do { x; } while (false)
> to handle the syntactic edge cases.
Well, if we're re-entertaining a function-like wrapper, we could just
as well avoid
getting back to the not-so-wonderful world of macros, and do
template T&& qEmit(T&& t) {return std::forward(t);}
___
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
On Fri, 21 Feb 2020 at 10:47, Allan Sandfeld Jensen wrote: > > On Sunday, 16 February 2020 19:32:02 CET Thiago Macieira wrote: > > On Saturday, 15 February 2020 06:23:52 PST Marc Mutz via Development wrote: > > > C++20 will contain new classes with emit() member functions > > > (wg21.link/P0053). While that will only pose problems for users that > > > include the new header after (almost) any Qt header, this > > > should serve as a second shot across the bows (after namespace > > > boost::signals) that we should change something. > > > > Orthogonal to your request: can we ask C++20 to change the name of this > > function? We've been #define'ing emit for nearly 30 years. > > Didn't C++20 just finalize, in any case? Yes, and the name change was discussed but rejected. ___ 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
On Fri, 21 Feb 2020 at 10:42, Alex Blasche wrote: > I think a fallback to > > somethingChanged() > > 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? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
