9

SO に関する質問の 1 つに対する私の回答は、Valentin Kuzub によってコメントされました。彼は、JIT コンパイラによってプロパティをインライン化すると、リフレクションが機能しなくなると主張しています。

ケースは次のとおりです。

class Foo
{
    public string Bar { get; set; }

    public void Fuzz<T>(Expression<Func<T>> lambda)
    {
    }
}

Fuzz(x => x.Bar);

Fuzz関数はラムダ式を受け入れ、リフレクションを使用してプロパティを見つけます。HtmlHelper拡張機能の MVC では一般的な方法です。

Barプロパティがインライン化されてもリフレクションが機能しなくなるとは思いません。これは、Barインライン化されtypeof(Foo).GetProperty("Bar")、有効な を返す呼び出しであるためですPropertyInfo。

これを確認していただけますか、またはメソッドのインライン化に関する私の理解が間違っていますか?

4

4 に答える 4

3

JIT コンパイラは実行時に動作し、アセンブリに格納されているメタデータ情報を書き換えることはできません。リフレクションはアセンブリを読み取り、このメタデータにアクセスします。したがって、JIT コンパイラからリフレクションへの影響はありません。

編集: 実際には、コンパイル中に C# コンパイラ自体が情報を「インライン化」する場所がいくつかあります。たとえば、定数、列挙型、およびデフォルトの引数は「インライン化」されているため、リフレクション中にアクセスすることはできません。しかし、それは間違いなくあなたの特定のケースとは関係ありません.

于 2011-07-14T10:44:59.753 に答える
1

ええ、もっと考えてみると、プロパティのインライン化が失敗する唯一の方法は、 INotifyPropertyChanged インターフェイスの正しい動作だと思います。

public Count
{
get {return m_Count;}
 set { m_Count=value;
      GetCurrentPropertyNameUsingReflectionAndNotifyItChanged();}
}

あなたが提案するように使用すると、実際にメタデータがアセンブリに存在し、そこからプロパティ名が正常に取得されます。

しかし、私たちは両方とも考えました。

于 2011-07-14T11:00:19.280 に答える
0

私は個人的に@Sergeyに同意します：

インライン化は JIT コンパイラ側で発生しますが、以前に生成されたメタデータを考慮すると、リフレクションに影響を与えるべきではありません。ところで、良い質問です。いいね +1

于 2011-07-14T10:48:50.160 に答える
0

式ツリーは、式自体ではなく式 (抽象構文ツリー) の表現であるため、インライン化することはできません。

デリゲートは、インライン化できる場合でも、プロパティで呼び出されているメソッドとターゲットに関するデータを保持します。

于 2011-07-14T11:22:12.880 に答える