質問はほとんど Qt の質問ではなく、C++ ネットワーク プログラミングの質問のようです。ビルド プロセスの一部としてQObject実行したくないため、カスタム派生クラスを明示的に使用することを基本的に嫌うようです。Qt 本体のビルド中に大量に実行されるmocため、何が悪いのかと主張する人もいるかもしれません。moc
非 Qt ベースの純粋な C++ ネットワーキングを探している場合、Boost ASIOは非常に堅実なソリューションです。
カスタム派生クラスなしで Qt ネットワークを使用する場合QObjectは、別のスレッドでコードを実行し、ブロッキングQTCPSocket呼び出しのみを使用できます。結局のところ、それQIODeviceはブロッキング インターフェイスを提供します。
最終的には、埋められたデータ構造が得られ、QML に渡す必要があります。
論理的には、データはデータ モデルであり、ビューは QML コードにあります。そのために使用できますQStandardItemModel。つまり、データが時間の経過とともに変化する場合のように、真のモデル ビュー コードを記述している場合です。QObject繰り返しになりますが、カスタム シグナルやスロットを作成せずに、独自の派生クラスを作成せずに、既存の 派生クラスを再利用しています。
本当に貧弱な人の回避策は、ネイキッドQObjectを取得し、 を介して動的プロパティ システムを使用してデータを入れることQObject::setPropertyです。動的なプロパティの変更が QML エンジンを介して見られるかどうかは覚えていません。それを確認するか、そのようなオブジェクトを単に定数として扱う必要があります。
これらはすべて、かなりばかげた予約に対する多くの回避策のようです。コードジェネレーターは優れており、時間を節約できます。複雑な C++ ベースの製品のビルド プロセスでは、レクサー/パーサー ジェネレーター、ステート マシン ジェネレーター、リモート プロシージャ コール ジェネレーター、テーブル ジェネレーター、テスト ケース ジェネレーターなど、いくつかの異なるコード ジェネレーターを使用する場合があります。これらのジェネレーターのいくつかを置き換えるようにコンパイラーを誘導しますが、それは問題を別の実行可能ファイルにプッシュするだけであり、時には非常に小さな針の穴からもプッシュします。