Q_PROPERTY NOTIFY 信号及其参数 [英] Q_PROPERTY NOTIFY signal and its argument

问题描述

我习惯用参数写我的propertyChanged"signal，这样接收端就不需要调用Q_PROPERTY的READ 函数显式.

I have the habit of writing my "propertyChanged" signals with an argument, such that the receiving end doesn't need to call the Q_PROPERTY's READ function explicitly.

我这样做是出于清楚和假设，即在 QML 数据绑定情况下，不需要对 getter 进行昂贵的"调用来实际获取值，因为它已经作为信号参数传递给 QML.

I do this out of clarity and the assumption that in a QML data binding situation, no "expensive" call to the getter needs to be done to actually fetch the value, as it's already passed to QML as a signal argument.

我的同事不同意，并说这违反了QML 风格"，对此我做出了回应，文档明确指出它可能有一个参数会采用基础成员的新值:

My colleagues disagreed and said it was against "QML style", to which I responded the documentation clearly states it may have an argument that will take the new value of the underlying member:

NOTIFY 信号必须采用零个或一个参数，该参数必须与属性的类型相同.该参数将采用属性的新值.

NOTIFY signals for MEMBER variables must take zero or one parameter, which must be of the same type as the property. The parameter will take the new value of the property.

文档中没有任何地方说明 QML 绑定系统使用此参数来防止在处理信号时对 getter 进行额外的函数调用.我知道这个调用可能会从 C++ 进行，因此不会对 C++ 进行昂贵的"QML 调用，但它仍然是一个额外的函数调用，原则上这可能会在多次更新的情况下导致明显的性能损失.

Nowhere in the documentation is it stated that the QML binding system uses this parameter to prevent an additional function call to the getter when handling the signal. I understand this call will probably be made from C++, so no "expensive" QML to C++ call will be made, but it still is an extra function call, which in principle could result in a visible performance penalty in case of many updates.

我尝试检查 QML 绑定源代码，但无法从中推断出任何东西.我想知道是否有人知道交易是什么:是否使用了信号参数?

I tried inspecting the QML binding source code, but couldn't infer anything from it. I wonder if someone knows what the deal is: is the signal argument used or not?

推荐答案

在 onPropertyChanged-signal 中传递改变的 properties 的 values虽然可能，但肯定不是QML 风格.

Passing the values of the changed properties in the onPropertyChanged-signal is, though possible, most surely not the QML style.

如果是这样，那么您应该期望至少对于它实现的基本类型(很容易显示)，它不是.

Would it be, then you should expect that at least for the basic types it is implemented, which is easily shown, it's not.

basictypes.qml

import QtQuick 2.7
import QtQuick.Controls 2.0

ApplicationWindow {
    id: root
    visible: true
    width: 400; height: 450

    property int num: 5
    Button {
        text: num
        onClicked: num += 1
    }
    onNumChanged: console.log(JSON.stringify(arguments), arguments.length)
}

正如您在输出中看到的那样，即使您更改了一种最基本的类型，例如 int，也没有传递任何参数.

As you can see in the output, that there are no arguments passed, when you change even one of the most basic types, such as int.

如果现在 QML 将使用可选但很少实现的传递值 this 会产生开销，因为您总是需要在使用它之前检查参数是否存在.虽然一个简单的检查并不昂贵，但如果它通常评估为 false，然后你使用解决方法，为什么要事先这样做?

If now QML would use the optional, but rarely implemented passed value this would create overhead, as you would always need to check the existence of the argument before using it. Though a simple check is not to expensive, if it usually evaluates to false, and then you use the workaround, why do it beforehand?

虽然我可能不排除，在官方的任何 onPropertyChanged 信号中都有任何传递的值，但在 QML 中添加的属性没有 property [type] [名称].大多数继承属性也没有(测试按钮:text、width、height).

Though I might not rule out, that there are any passed values in any onPropertyChanged-signals in the official realse, there are none for properties added in QML with property [type] [name]. There also none for most inherited properties (tested the Button: text, width, height).

这篇关于Q_PROPERTY NOTIFY 信号及其参数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！