問題タブ [static-reflection]

私は LINQ 式を使用した静的リフレクションについて勉強してきました - とてもクールです!

私が持っていた1つの考え-あるクラスが、別のクラスで行われた静的リフレクションに基づいて、あるクラスでフィールドを「生成」することは可能ですか? ここで何度も見た Builder パターンを具体的に考えています。構築したいクラスに一致するビルダーのフィールドを「生成」する流暢な nhibernate スタイルのプロパティ登録を行いたいと思います。このようなもの：

次のようなコンストラクター構文をサポートします。

これらすべてのポイントは、Color のプロパティの定義を繰り返さなければならない回数を減らすことです。私はこれで遊んだ：

これは確かに機能し、プロパティを同じ回数リストしますが、冗長で柔軟性が低く感じます。ここで匿名型の何かをすることができるはずですか？

コントローラーの標準の return ステートメントを見てみましょう。

このことをコンパイル時に安全にする方法はありますか? 静的反射またはその他のトリックを使用していますか?

これは、Oliver Hanappiがスタックオーバーフローに投稿した静的リフレクション コードです。

私はパブリックラッパーメソッドを持っています:

次に、独自のメソッドのショートカットを追加しました

GetMemberName(Expression expression)スイッチのさまざまな分岐を必要とする、または利用するコードの例は何ですか? このコードは、強く型付けされたものを作ることができますか?

2 つの類似したオブジェクト (C#) 間のバインドが必要です。

TypeA のフィールドが変更されたら、TypeB の一致するフィールドを更新する必要があります。

IntField は int 型の Value フィールドを持つオブジェクトであるため、TypeB の更新は次のように記述できます。

私が正しく理解していれば、TypeB を TypeA にバインドするために INotifyPropertyChanged を使用すると、ボイラープレートが発生します。

また：

• 私は両方のタイプのコードにアクセスできますが、TypeB は変更したくありません。
• TypeA や TypeB などの型のペアが 15 まであります。ボイラープレートは避けたいと思います。
• パフォーマンスは非常に重要であるため、リフレクションは推奨されるオプションではありません。
• おそらく静的反射はオプションですか？聞いたことはありますが、次の点についてはわかりません。
  • ボイラープレートなしで使用する方法。
  • その性能。
  • 同じタイプのペアの異なるインスタンスに使用します (つまり、a1Instance->b1Instance、a2Intance->b2Instance など)。

編集：

IntField はクラスです。これは、システムに存在する別のタイプのデータ バインディングに使用されます (複雑で、システム全体がこれに依存しています)。一般的なバインド可能なフィールドを表すクラスから継承します。ここにその一部があります：

だから私はメタクラスをとても楽しみにしていました。その後、メタクラスを追加する前に、まず言語でリフレクションと具体化が必要だと彼らは考えているため、 c++23には含まれないだろうと聞きました。

C++23のリフレクションを見ると、具体化機能があるようです。メタクラスが何をするかを解決するのに十分ですか。つまり、メタクラスは単なるシンタックス シュガーですか?

現在の提案を使用して、次のような型を書いている人を複製できますか:

次のような型を生成します。

さらに進むには、似たようなものを取ります

生成できること

live example、どちらも私がメタクラスに興奮した種類の例です。

構文についてはあまり心配していません (ライブラリを記述して poly 値またはインターフェイスを作成できることは便利ですが、正確な構文はそうではありません)。