Re: [Development] QProperty and library coding guide
On Sunday, 19 July 2020 14:42:24 PDT Giuseppe D'Angelo via Development wrote: > * change /*2*/ to use ASM. We know the ABI of the platforms we support > and we know how to calculate the correct pointer value, we just need to > stop C/C++ from reason about it and flagging it as possible UB. Yes, > it's a crude hack... ASM is not a solution. There's at least one major compiler (MSVC) that doesn't allow any assembler. But see Ville's email. I think the pointer arithmetic is actually fine. Would be fine too with uchar*. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ 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 13:08, Edward Welbourne wrote: Il 16/07/20 12:43, Volker Hilsheimer ha scritto: For pre-C++20 (where it’s possible to have zero-size structs), and for compilers that don’t respect the [[no_unqiue_address]] attribute, all these struct-instances are put into a union. In that case, a class using QProperty will be larger (by the same amount no matter the number of properties) than the same class in Qt 5. With C+++ 20 and compilers that do respect [[no_unique_address]], the size and layout of these classes will be the same. Giuseppe D'Angelo (16 July 2020 12:58) requested: Could anyone please illustrate with some code snippets how to achieve this, in practice, in a number of use cases? E.g. client code (non pimpled QObject subclass), (Qt) library code (pimpled QObject subclass), etc.; gadgets (does QProperty work there?); with and without other Q_PROPERTY/QProperty already present, etc. As noted in my last mail, documentation is still lagging. Several of us - previously ignorant of the new system - are currently helping Ulf and Fabian with conversion. We are, in the process, helping to debug the draft instructions for how to convert and point out gaps in the system that make this harder than it should be. Hopefully, once we've spent a week or two hassling Ulf and Fabian with questions, they'll have the right things in place and know how to document it clearly. However, doing so today would soak up some of their time that is better spent getting the system into the right state so that the documentation doesn't need repeated updates ... Please be patient, we are working on this, Please understand that waiting with this will also make other contributors who will need to deal with QProperty wait, including those who will need to OK such changes (such as Thiago). So, you are making dozens of people wait to protect the time of two people? That doesn't make much sense IMO. All that was asked for were some examples, not fully fledged detailed documentation. Cheers, André Eddy. ___ 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
Il 19/07/20 20:42, Thiago Macieira ha scritto:
In that sense, Peppe's suggestion of C++17 offsetof is better.
To clarify, I was proposing to do something like this:
Type Klass::_qt_property_api_propertyName::value() const
{
/*1*/ const size_t propertyMemberOffset =
reinterpret_cast(&(static_cast(nullptr)->propertyName));
/*2*/ const auto *thisPtr = reinterpret_cast(reinterpret_cast(this) - propertyMemberOffset);
return thisPtr->d_func()->property.value();
}
* change /*1*/ become offsetof(Klass, propertyName);
* change /*2*/ to use ASM. We know the ABI of the platforms we support
and we know how to calculate the correct pointer value, we just need to
stop C/C++ from reason about it and flagging it as possible UB. Yes,
it's a crude hack... :(
My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
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 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.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
On Sunday, 19 July 2020 03:51:00 PDT Oswald Buddenhagen wrote:
> - the compiler becomes intentionally belligerent, in which case an
>override switch will be provided as well (if not instantly, then after
>the outcry that immediately follows)
Even if that were the case, we'd need EVERYONE's code to use this switch. Not
just when Qt is being built, where we control the options. We'd need all our
users to use it, in their buildsystems, whichever they may be.
That's why this is not acceptable.
>
If Peppe's idea doesn't work, then:
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;
}
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
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] QProperty and library coding guide
On Sun, Jul 19, 2020 at 01:14:08PM +0200, Giuseppe D'Angelo via Development wrote: offsetof is conditionally-supported for non standard layout classes in C++17.: oh, good. that means that the second line should also keep working, as that is semantically equivalent with offsetof being meaningful, afaict. On Sun, Jul 19, 2020 at 01:20:12PM +0200, Giuseppe D'Angelo via Development wrote: Il 19/07/20 12:51, Oswald Buddenhagen ha scritto: - the compiler becomes intentionally belligerent, in which case an override switch will be provided as well (if not instantly, then after the outcry that immediately follows) File under "surely no compiler will optimize away X!", for X in [...] (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).) ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
Il 19/07/20 12:51, Oswald Buddenhagen ha scritto: - the compiler becomes intentionally belligerent, in which case an override switch will be provided as well (if not instantly, then after the outcry that immediately follows) File under "surely no compiler will optimize away X!", for X in * unspecified pointer comparisons * signed integer over/underflows * data races (on bitfields) * volatile in lieu of proper atomic access * proving that a loop doesn't terminate, hence the loop is never entered, and applying dead code optimization to it * ... To do any of the above is not belligerent, AND you have no way to switch the above optimizations off. (Also, you don't want to.) In other words: this is playing with fire in the long term run, that's why I suggested to bypass the C++ abstract machine, rely on ABI and use ASM. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
Il 19/07/20 12:51, Oswald Buddenhagen ha scritto: - the compiler somehow starts to actually make use of the freedom granted by the fact that QObject is not standard-layout (this, btw, is also the reason why peppe's suggestion to use offsetof doesn't fix UB). offsetof is conditionally-supported for non standard layout classes in C++17.: http://eel.is/c++draft/support.types.layout#1.sentence-2 I haven't found any note in GCC/Clang/MSVC docs saying that they won't support it in this case, hence it's supported. http://eel.is/c++draft/intro.compliance#:behavior,conditionally-supported My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
On Sat, Jul 18, 2020 at 10:10:41AM -0700, Thiago Macieira wrote: On Friday, 17 July 2020 23:32:41 PDT Simon Hausmann wrote: This hack has been in QtQml in production since its release in 2010 (see static cast selector). It would be a shame if this stopped working The problem here is the damage that can happen if a breakage happens. i can think of only two ways how this can stop working: - the compiler becomes intentionally belligerent, in which case an override switch will be provided as well (if not instantly, then after the outcry that immediately follows) - the compiler somehow starts to actually make use of the freedom granted by the fact that QObject is not standard-layout (this, btw, is also the reason why peppe's suggestion to use offsetof doesn't fix UB). however, this would also come with a massive BC break, in which case we'd have bigger problems anyway. so it's guaranteed that a compat switch would be provided as well, exactly because much code wants to stay BC. anyway, i consider this case entirely hypothetical, as there is no reason to break this when compiling for real hardware (or something that resembles it, like wasm, afaik); it might be different for some vms. So what's the [efficient] non-UB solution? ;-) ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
On Sat, 18 Jul 2020 at 03:58, Ulf Hermann wrote: > > > I must be missing something. I tend to think of eventloops with notify > > signals are an improvement over polling. You statement seems to say > > that asking for a value is better, and notifications are to be avoided? > > I'm not saying that you should go back to polling. In the case that you > have genuine events, for example input or network activity, signals may > just be the thing you need. This whole discussion is specifically about > properties and their _change_ signals. > > Mind that the propagation of dirty flags across a binding graph is a > kind of "change signal" in its own right. With QProperty, we just don't > calculate the values right away when we notice that a related property > has changed. Why is that? > > Properties can change fairly often, and synchronously triggering a chain > of calculations whenever some property changes can be inefficient and > can lead to unexpected intermediate values. This is why we introduce > lazy evaluation for property bindings. > > With this system, on some level, you indeed have to poll a property to > make something happen outside the system. However, certain technologies > are inherently based on polling. For example the scene graph rendering a > frame every 16ms will poll for changed items every time. For this, a > lazy evaluation strategy makes more sense than the usual change signals. > > If you want to take advantage of lazy evaluation in such places, you > should stop using the change signals there, though. Whenever a property > has a change signal, it and everything it depends on needs to be > evaluated eagerly. > > best, > Ulf Will language bindings be able to take advantage of the new QProperty system? For example, will it be possible to create a lazy-evaluated property binding from non-C++ code? (For reference, Qt for Python currently creates new properties this way: https://wiki.qt.io/Qt_for_Python_UsingQtProperties ) Regards, Sze-Howe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
