構造体のサイズについて

Question

質問

クラスまたは構造体の選択より、

"インスタンスのサイズは 16 バイト未満である。"

とあったので、構造体のサイズについて調べてみたのですが、プロパティ・メソッドがサイズに含まれないのはなぜなのでしょうか?

該当のソースコード

struct MyData
{
    private int x; // 4byte
    public int X   // 4byte
    { 
        get { return x; }
        set { x = value; }
    }

    public void GetThree()  // 8byte ポインタ?
    {
        Console.WriteLine(x);
        Console.WriteLine(x);
        Console.WriteLine(x);
    }
}

class MyApp
{
    static void Main()
    {
        Console.WriteLine(Marshal.SizeOf(typeof(MyData))); // 4
    }
}

試したこと

コードを実行する前は、int x:4 + int X:4 + void GetThree():8 = 16 バイトと思っていたのですが
期待する結果とは異なり、Marshal.SizeOf() の結果は"4"と出力されました。

疑問点

• メソッドは、64bit の場合ポインタのサイズで 8 バイトではないのでしょうか?
• プロパティは、int x を包括?するための仕組みなのでサイズはないのでしょうか?

Answer 1

Marshal.SizeOf Method

The size returned is the size of the unmanaged type. The unmanaged and managed sizes of an object can differ.

アンマネージ構造体にはプロパティもメソッドもありません。
なので省かれます。

Comments

[Ojawa]

* マネージ構造体
* アンマネージ構造体

上記は、GC 内で展開されるか、GC 外で展開されるかの違いと Marshal.SizeOf() がアンマネージのサイズを返却することは理解しました。
しかし、私の定義した構造体はアンマネージ構造体である理由が調べてもわかりませんでした。

追加の質問となり申し訳ないのですが、

* int x; // アンマネージ領域
* プロパティ・メソッド // マネージ領域

上記で展開されるという意味で合っていますでしょうか。

[Zuishin]

KSwordOfHaste さんのおっしゃる通りメソッドおよびプロパティは構造体内部に領域を持つのではなくコード領域にあります。そしてそれへの参照は定数としてコンパイルされます。

Marshal.SizeOf はアンマネージ構造体にマーシャリングされた場合、どのサイズになるのかという数値を計算して返します。つまりこの時点では計算上の架空のサイズです。

マネージ構造体のサイズを取得するには、Marshal.SizeOf メソッドではなく、sizeof 演算子を使ってください。ただし、unsafe コンテキストが必要であるなど、いくつかの制限があります。

また 16 バイトというのは目安でしかなく、それ以上の構造体を作ることも可能です。ただし構造体は値型なので変数への代入やメソッドへの引き渡しにコピーが発生するため、大きいものはパフォーマンスが落ちる傾向があります。

16 バイトにはそれほどこだわらず、基本的に class を使い、特に構造体の方が良いパフォーマンスを得られると確信した場合にのみ構造体を使うのが良いでしょう。

Answer 2

ご質問の例でいえばインスタンス上に必要な情報は

private int x;

これだけです。

プロパティ・メソッドがサイズに含まれないのはなぜなのでしょうか?

大抵のコンパイラー/インタープリタ言語でも同様なのですが、メソッドの類はインスタンス自身の内側に領域を持ってはいません。structだけでなくclassのインスタンスもそうです。

理由はどの実体であってもメソッドの実体(プロセッサーの機械語ないしは仮想マシンのIL/bytecodeの並び）は必ず同一になるからです。個々のインスタンスに依存しない同一の情報を各々のインスタンスの領域にわざわざ記録するのはメモリー領域の無駄使いでしかなく不合理です。

メンバー関数やプロパティーについて以下のコードをごらんください。

using System;

public struct S {
  public int x;
  public void m1() { Console.WriteLine("m1: " + x); }
  public int X
    {
      get { return x; }
      set { x = value; }
    }
}

public static class SImpl {
  public static void m2(ref S self) { Console.WriteLine("m2: " + self.x); }
  public static int getX(ref S self) { return self.x; }
  public static void setX(ref S self, int value) { self.x = value; }
}

class App {
  public static void Main() {
    S s = new S() { x = 111 };
    s.m1();
    SImpl.m2(ref s);

    s.X = 123;
    Console.WriteLine("s.X = " + s.X);

    SImpl.setX(ref s, 456);
    Console.WriteLine("s.getX = " + SImpl.getX(ref s));
  }
}

この構造体はm1というメソッド、Xというプロパティーを持ってますが、SImplにあるm2, getX, setXを用いるとm1やXを使用するのとまったく同じことができていることがおわかりでしょか？
実はコンパイラーはm1やXをちょうどこんな雰囲気に展開してくれているのです。

そのためSの領域自体の中にはxというフィールドしか必要なく、当然ながらSizeOfも4を返すというわけです。

ソフトウェアはどんなものであれ「合理的」に設計されています。プログラムの実行効率（メモリー量やスピード）に大きな影響を及ぼす言語処理ソフトウェア(コンパイラーやランタイム)では特に効率に関する合理性の追求が顕著であり、常に可能な限り最高の効率を目指して設計されているのが普通です。

アプリケーションを書く上では仕様書を参照し「どういう仕様であるか」を知っていさえすれば充分と言えますが、もう少し突っ込んで低水準な言語処理系の本質に関して学ぶと仕様の根拠が見えてくることがあります。自分はC++に初めて触れたときC++がvirtualなメンバー関数をどのようにして実現しているかコンパイルされたコードを観察して「うーむ、なるほどうまいこと考えるものだ」と感心したことを覚えています。こういうことを少し学んでおくと「なぜこういう仕様になっているか」「何に気を付けなければならないか」がより深く把握できる気がします。

そういう意味で質問者さんが「実際にサイズがどうなるか」を調べたり「それが何故か」を考えておられるのは価値あることだと思いました。

Comments

[Ojawa]

詳しい解説ありがとうございます。

* 構造体の領域には、int x のフィールドがある。
* プロパティ・メソッドはコンパイル時に別の領域に展開される。
* プロパティ・メソッドには、構造体の型情報よりアクセスしている。

上記のことから、構造体のサイズを取得する場合、構造体の領域内にある int x:4 バイトが返却されるイメージで合っていますでしょうか。

[Ojawa]

> そういう意味で質問者さんが「実際にサイズがどうなるか」を調べたり「それが何故か」を考えておられるのは価値あることだと思いました。
ありがとうございます。まだまだ勉強することがたくさんあるので、これからも頑張ります。

[KSwordOfHaste]

> 合っていますでしょうか。
あってます。

[Ojawa]

"インスタンスのサイズは 16 バイト未満である。"の条件としては、

* 構造体のメンバメソッド・プロパティは制限なし。
* 構想体のメンバフィールドは、16 バイト未満であること。

ということなのですね。
ありがとうございます、わかりやすい解説を頂きすーっと理解することが出来ました。

Answer 3

クラスと構造体の使い分けで解説されていますが

パフォーマンスを理由に「クラスか構造体か」を選択するのなら
16バイトが閾値となる。(ので参考にしてね)

くらいの意味で、マイクロソフト自身も守っていないガイドラインなので
あまり深く考える必要はないと思います。