Re: [Development] QProperty and library coding guide
On Wednesday, 22 July 2020 14:17:26 PDT Bernhard Lindner wrote: > Hi! > > > Breaking BC means subtle errors that are hard do detect and debug. > > Couldn't those subtle errors be replaced by some clear and understandable > error? Like some explicit binary compatibility check? Such a test does not exist, comprehensively. We can put a few common things in an ABI marker, like the size of QObject, the actual type qreal maps to, the name of the C++ standard library we linked against, etc. But that won't catch everything and it's the minor things that come back to bite you. Neither the ABI test by the Linux Foundation, nor abigail, nor our own tst_bic are exhaustive. And they're way too slow for a regular run. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
Hi! > Breaking BC means subtle errors that are hard do detect and debug. Couldn't those subtle errors be replaced by some clear and understandable error? Like some explicit binary compatibility check? -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
On Wednesday, 22 July 2020 09:55:31 PDT André Pönitz wrote: > How often do we think people are actively taking advantage of Qt's BC > promise (and how often do we hold this promise, and how often is this > relevant as we do not promise to change behaviour while keeping BC)? That is a good question. I don't want to minimise it, just to add. Have at least one category of users that require it, that being the Linux distributions. So long as we support them, we have to provide a way to have BC. And if we do have such a way, how much does it hurt to extend it everywhere? We've seen users of not-systemwide-Qt-OSes having BC issues too. Large projects often have binary artifacts they'd rather not recompile every time. Those teams can be taught to recompile, but that's not their current practice. Breaking BC means subtle errors that are hard do detect and debug. Finally, there's the issue of binary-only components by third parties. If we ever want to support such an ecosystem (we could call it "Qt Marketplace"), we must have as few binary-incompatible versions as possible. It's already difficult to support, for desktops alone: - Linux GCC 64-bit - Apple Clang 64-bit [*] - Windows MinGW / Clang 32-bit - Windows MSVC 2019 / clang-cl 32-bit - Windows MSVC 2019 / clang-cl 64-bit Breaking BC frequently means replicating this table for every BC breakage level. [*] whether that's a single Universal build or if it is released as separate x86-64 and ARM64 builds remains TBD. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
On Wed, Jul 22, 2020 at 10:27:14AM +, Lars Knoll wrote: > > On 22 Jul 2020, at 11:38, Shawn Rutledge wrote: > > > > > >> On 2020 Jul 16, at 11:19, Ulf Hermann wrote: > >> > >> Data bindings are a cornerstone of most modern UI frameworks, and Qt is > >> actually late to the game. If we want Qt to stay relevant, then it needs to > >> offer the same kind of convenience and performance that other frameworks > >> offer. This would be an argument for converting all existing properties, > >> and > >> paying the price, just to make the binding API available. > > > > Has someone done a survey of how bindings are implemented in other > > frameworks? > > Maybe there is a cool trick out there that we are missing, which would > > enable > > a big leap in efficiency. > > I don’t know of anybody who has done this for C++ yet. I do believe the design > we have with QProperty is pretty good from an API perspective as well as > efficient. > > The problem we’re having purely comes from the fact that we’re trying to > provide > BC between versions and are hiding our data behind a d-pointer. If we'd give > this up the whole problem would go away. Then the elephant in the room is the question how valuable BC in generally is for normal Qt users. How often do we think people are actively taking advantage of Qt's BC promise (and how often do we hold this promise, and how often is this relevant as we do not promise to change behaviour while keeping BC)? For me personally, source compatibility is much more valuable, and BC is a "good enough" approximaton for that insofar that having to keep BC prevents a lot of changes that would also break SC. Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
On Wednesday, 22 July 2020 08:52:17 PDT Simon Hausmann wrote: > > On Wednesday, 22 July 2020 00:05:34 PDT Simon Hausmann wrote: > > > That said, this very construct that you're referring to, that is what > > > has been in user > > > code since QtDeclarative was been released [1]. Anybody using > > > qmlRegisterType() will > > > up with local template code that does this. It's impact wise as if moc > > > generated it. > > > > Have you hearad of a Schrödinbug? Not a Heisenbug. > > > > It's a bug that was always there but hurt no one. Until someone noticed > > it. > > Now it will keep reappearing all the time. > > Hehe. Maybe it’s more like a SchödinUB Anyway, I looked at the code in question and though it is UB, it's also optional. It only kicks in if the type being registered multiply-derives from one of three helper classes. Most user-registered types don't. There's also a very simple fix for that. Instead of trying to record the offset in the QML type registry, record the pointer to a function that takes a pointer to QObject and returns the adjusted pointer to those classes. This could have been done in 2010. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
On Wednesday, 22 July 2020 08:50:50 PDT Lars Knoll wrote: > I still don’t understand why you think this should be necessary. All we need > to do is clearly document that enabling/disabling the support for this > feature is not binary compatible and make sure users don’t mix by accident. First, I was talking about the defaults. Are we ok with those defaults? Are we also ok with the communication that goes along with it? I don't want Linux distributions that don't follow Qt development as closely to think they can turn off [[no_unique_address]] support so they can use an older GCC, only to find out later that they can't turn that back on. Second, I don't want the option to turn *off* [[no_unique_address]] in GCC and Clang. We have enough binary applications using Qt that get installed in Linux systems that mixing plugins and libraries is bound to happen, with crashes left and right. I am ok with adding an option to turn it on with MSVC and on Apple OSes, since there's never a system-wide Qt in those. Possibly Android too. So the minimum version of GCC for Linux distributions must be 9.0. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
Thiago Macieira schrieb am Mi. 22. Juli 2020 um 17:46: > On Wednesday, 22 July 2020 00:05:34 PDT Simon Hausmann wrote: > > That said, this very construct that you're referring to, that is what > > has been in user > > code since QtDeclarative was been released [1]. Anybody using > > qmlRegisterType() will > > up with local template code that does this. It's impact wise as if moc > > generated it. > > Have you hearad of a Schrödinbug? Not a Heisenbug. > > It's a bug that was always there but hurt no one. Until someone noticed > it. > Now it will keep reappearing all the time. Hehe. Maybe it’s more like a SchödinUB ;-) > > PS: you sent the email to me alone. Did you mean to? > Ooops that was not intentional:) Simon > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
> On 22 Jul 2020, at 17:30, Thiago Macieira wrote: > > On Wednesday, 22 July 2020 03:24:30 PDT Lars Knoll wrote: >> no_unique_address is coming and making that problem go away. It’s available >> on all compilers except MSVC today (see >> https://en.cppreference.com/w/cpp/compiler_support#cpp2a). >> >> We want things to work on C++17 and that’s what we have. But we can and >> should plan for C++20. > > Please reconfirm you are willing to: > > a) require GCC 9.0 and Clang 9.0 > b) not use [[no_unique_address]] in MSVC and clang-cl until Qt 7 > c) drop support for any other compilers until they support > [[no_unique_address]] > > (I think we only have two other supported compilers: Green Hills' and Intel's) I still don’t understand why you think this should be necessary. All we need to do is clearly document that enabling/disabling the support for this feature is not binary compatible and make sure users don’t mix by accident. Cheers, Lars > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel DPG Cloud Engineering > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
On Wednesday, 22 July 2020 03:24:30 PDT Lars Knoll wrote: > no_unique_address is coming and making that problem go away. It’s available > on all compilers except MSVC today (see > https://en.cppreference.com/w/cpp/compiler_support#cpp2a). > > We want things to work on C++17 and that’s what we have. But we can and > should plan for C++20. Please reconfirm you are willing to: a) require GCC 9.0 and Clang 9.0 b) not use [[no_unique_address]] in MSVC and clang-cl until Qt 7 c) drop support for any other compilers until they support [[no_unique_address]] (I think we only have two other supported compilers: Green Hills' and Intel's) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
On 16-07-2020 17:40, Volker Hilsheimer wrote:
We need “text” to be a public member of QAction, otherwise we can’t do
action->text();
That ‘text” member is a struct with a bunch of operators overloaded, so that we
can do either
qDebug() << action->text();
qDebug() << action->text;
and
action->setText(“foo”); // no binding
action->text = document->title; // still no binding
action->text = Qt::makePropertyBinding(document->title); // yay binding!
Thank you for this example of how these new properties are going to look
from a user code perspective. I have some questions left if you don't mind?
First, say I have another QProperty that has a binding to this
action->text property. I assume that doing `action->setText("foo")` or
`action->text = document->title()` will both result in this binding
being triggered, and thus, triggering side-effects? I would expect such
in the first case, but not so much in the second as this _looks_ like an
assignment to a member variable.
Second, say that I initialized action->text like you do in your last
example, creating a binding. And then I assign to it using, say,
`action->text = document->title();` Does that work? Do we overwrite the
binding? Is it possible to prevent that override? This was a problem in
QML as well where one could accidentally overwrite bindings. I assume
there is a way to mimic adding `readonly` like you can in QML?
Third, you show that `qDebug() << action.text()` and `qDebug() <<
action.text` is the same. Is that really all that desirable? Somebody
already pointed out this issues with doing an `auto actionText =
action.text();` elsewhere in this thread, and I am wondering if you'd
not want to output some debug info on the property itself, in stead of
just the value?
Don't get me wrong: I think the syntax where you're basically able to
use the property as if it was a member variable, basically coming back
full circle. But I also think it may be confusing for everyone expecting
an assignment to something that looks like a member to, well, behave
like that. Is there a reason why this setup was chosen over a more
conventional but admittedly less cool:
action->text->set("foo");
action->text->set(document->title->get());
action->text->bind(document->title);
qDebug() << action->text.get();
Cheers,
André
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
> On 22 Jul 2020, at 11:38, Shawn Rutledge wrote: > > >> On 2020 Jul 16, at 11:19, Ulf Hermann wrote: >> >> Data bindings are a cornerstone of most modern UI frameworks, and Qt is >> actually late to the game. If we want Qt to stay relevant, then it needs to >> offer the same kind of convenience and performance that other frameworks >> offer. This would be an argument for converting all existing properties, and >> paying the price, just to make the binding API available. > > Has someone done a survey of how bindings are implemented in other > frameworks? Maybe there is a cool trick out there that we are missing, which > would enable a big leap in efficiency. I don’t know of anybody who has done this for C++ yet. I do believe the design we have with QProperty is pretty good from an API perspective as well as efficient. The problem we’re having purely comes from the fact that we’re trying to provide BC between versions and are hiding our data behind a d-pointer. If we'd give this up the whole problem would go away. Cheers, Lars > > Do you have links to docs for the ones that you think look elegant? > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
On 22 Jul 2020, at 00:14, Ville Voutilainen mailto:ville.voutilai...@gmail.com>> wrote: On Wed, 22 Jul 2020 at 00:18, Volker Hilsheimer mailto:volker.hilshei...@qt.io>> 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? Yes, there are ways to solve at least part of those issues. Using auto together with those properties is something to consider. But I don’t think we should throw away the whole concept because of it. We can partly solve it by e.g. making the properties not copyable. And we do have similar problems other places (and so does the STL btw). We e.g. need qAsConst() when using our containers with ranged-for our containers. But IMO that is no reason to throw the baby out with the bath-tub water. 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. no_unique_address is coming and making that problem go away. It’s available on all compilers except MSVC today (see https://en.cppreference.com/w/cpp/compiler_support#cpp2a). We want things to work on C++17 and that’s what we have. But we can and should plan for C++20. Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
> On 21 Jul 2020, at 22:51, Ville Voutilainen > wrote: > > 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. +1. Movable types are UB, still we do not want to sacrifice those, as they give a huge performance benefit, esp. for. Refcounted shared types. We now have something where we aim for API equivalence between an API we can offer our users and the additional jumps we have to do to achieve the same thing while hiding our data (purely because we want to offer BC). API equivalence is extremely important if we want this to work. The current implementation has a bit of UB in it that does work on all current compilers. It’s not inline in user code, so if a new compiler comes up that requires fixing this using e.g. inline assembly we can still do this (as taking the new compiler into use requires a recompile anyway). So I don’t really see where we have a huge problem with the current design that is not solvable without sacrificing it. Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
> On 2020 Jul 16, at 11:19, Ulf Hermann wrote: > > Data bindings are a cornerstone of most modern UI frameworks, and Qt is > actually late to the game. If we want Qt to stay relevant, then it needs to > offer the same kind of convenience and performance that other frameworks > offer. This would be an argument for converting all existing properties, and > paying the price, just to make the binding API available. Has someone done a survey of how bindings are implemented in other frameworks? Maybe there is a cool trick out there that we are missing, which would enable a big leap in efficiency. Do you have links to docs for the ones that you think look elegant? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
