2017-08-23 15 views
0

私は(public :セクションで定義された)データメンバC++コードから一部Q_PROPERTYに対応する読み取り、場合Q_PROPERTYREADなしCONSTANTMEMBER以外であれば、任意の欠点はありますか?直接リード部材プロパティC++コードから

class Value 
    : public QObject 
{ 

    Q_OBJECT 

    Q_PROPERTY(int x MEMBER x NOTIFY xChanged) 

public : 

    Value(QObject * const parent) 
     : QObject{parent} 
    { ; } 

    int x = 0; 

Q_SIGNALS : 

    void xChanged(int x); 

}; 

//... 
Value v; 
//... 
std::cout << v.x; 

Q_EMIT xChanged(123);は場合に自動的に呼び出されるので、確かに書くことv.setPropery("x", 123);を使用して魅力的です。しかし、毎回v.xの代わりにv.property("x")と書くのは面倒ですが、C++コードからプロパティの値を読み取る必要があるだけです。 BTWはランタイムの意味では最適ではありません、確かです。

上記のようなクラスのデータメンバーを直接読み込んだ場合、C++とJavascript/QMLコードの間に悪影響はありますか?

+0

OOPパラダイム(カプセル化)のためにフィールドを公開するのは悪いです。だから、あなたが安全で読みやすいコードを気にしなければ、フィールドをパブリックメンバーとして使うことができます。 –

+0

QMLの観点から@DmitrySazonov私はデータメンバーに直接アクセスできます。彼らは一般公開されています。 C++側は、OOPの意味でQML側に反映されています。 – Orient

+0

@DmitrySazonov公開された唯一の欠点は、私が 'これ '以外のすべてに対して' const'にすることができないことです。 – Orient

答えて

1

上記のようなクラスのデータメンバーを直接読み込んだ場合、C++とJavascript/QMLコードの間に悪影響はありますか?

いいえありません。しかし、あなたはアクセサを持って、直接メンバーを公開しないでください。

class Value : public QObject 
{ 
    Q_OBJECT 
    Q_PROPERTY(int x MEMBER m_x NOTIFY xChanged) 
    int m_x = {}; 
public : 
    Value(QObject * parent = {}) : QObject{parent} {} 
    int x() const { return m_x; } 
    Q_SIGNAL void xChanged(int); 
}; 
+0

これを 'READ'関数として指定する方が良いでしょう。現在のところ、getterを持っていて、 'Q_PROPERTY'でそれを使わないのは間違いです。 – Orient

+0

この場合、 'x'はQML側からreadonlyプロパティになりましたが、 – Orient

+0

でもC++のアクセサーがあります。メンバーを介してメタオブジェクトシステムに公開しても問題ありません。しかし、アクセサーの変更は省略され、 'Q_PROPERTY'と同期されていない可能性があり、問題があると主張することができます。 'MEM'を微調整して、' MEMBER'のみのプロパティのためのアクセサを持つヘルパークラスを生成し、そのクラスから継承することができます。例: 'class Value:public QObject、public ValueAccessors {friend ValueAccessors; ...}; '。簡単に行うことができ、 'moc'がクラスに宣言を追加できないという問題を解決します。 –

-1

それはあなたがプロパティが読み取りまたは書き込まれたときにコードを実行する場所を失いそうと知っQ_PROPERTYにMEMBERを使用して完全に罰金です。

MEMBERを使用して、ドキュメントに書かれているように、READまたはWRITEを指定して、混合アプローチを使用できることに注意してください。

Q_PROPERTY(type name MEMBER memberName [(READ getFunction | WRITE setFunction)]) 

最初はMEMBERを使用できますが、読み書きにフックが必要な場合は、後でゲッター/セッターを追加できます。

キーワードMEMBERを使用すると、空のゲッターとセッターがすべて同じように見える無用なボイラープレートを避けると便利です。

+0

あなたはトリビアを書く。問題はそれに関するものではありません。あなたは私が問題にしていることをほとんど繰り返す。 – Orient

+0

質問は、C++やQMLとのやりとりにセッターとゲッターを持たないことが出てきたら、メンバーの使用についてです。答えは「それは完璧です」と私は使い方についての長所と短所を詳述していますメンバー。 私はちょうど言ったでしょう: "問題ありません"? – GendoIkari

+0

アルゴリズムは次のものです:まず最初に質問とすべての解答を読んでください。この質問については、いくつかの詳細を明らかにする議論もあります。もしあなたが思うのであれば、他の参加者とは違って、あなたは本当に新しい*情報で答えを出すか、コメントを投稿するかもしれません。あなたの答えは、質問自体に既に提供されている背景情報だけで構成されています。 Qt Property Systemについて読んでも問題ありません。私はそれに精通しており、質問の最初の2つの行でこれを実証しました。 – Orient

関連する問題