ここでの議論に続いて、可変構造体は「悪」である（この質問への回答のように）とのコメントを何度か読みました。

C＃の可変性と構造体の実際の問題は何ですか？

構造体は値の型であり、渡されたときにコピーされます。

したがって、コピーを変更する場合は、そのコピーのみを変更し、元のコピーや周りにある他のコピーは変更しません。

構造体が不変の場合、値で渡された結果のすべての自動コピーは同じになります。

変更したい場合は、変更されたデータを使用して、構造体の新しいインスタンスを作成することで意識的に行う必要があります。（コピーではありません）

どこから始めるか;-p

Eric Lippertのブログは常に引用に適しています。

これは、可変値型が悪であるもう1つの理由です。常に値の型を不変にするようにしてください。

最初に、変更が非常に簡単に失われる傾向があります...たとえば、リストから物事を取得する：

Foo foo = list[0];
foo.Name = "abc";

何が変わったの？何も役に立たない...

プロパティと同じ：

myObj.SomeProperty.Size = 22; // the compiler spots this one

あなたに強制する：

Bar bar = myObj.SomeProperty;
bar.Size = 22;
myObj.SomeProperty = bar;

それほど重要ではないが、サイズの問題がある。可変オブジェクトには複数のプロパティがある傾向があります。まだあなたは2を持つ構造体がある場合intの、string、DateTimeそしてbool、あなたは非常に迅速に、多くのメモリを通じて書き込むことができます。クラスを使用すると、複数の呼び出し元が同じインスタンスへの参照を共有できます（参照は小さい）。

私は悪とは言いませんが、可変性は多くの場合、最大限の機能を提供しようとするプログラマー側の熱意の表れです。実際には、これは多くの場合必要ありません。その結果、インターフェースが小さくなり、使いやすくなり、間違って使用することが難しくなります（=より堅牢）。

この1つの例は、競合状態での読み取り/書き込みおよび書き込み/書き込みの競合です。書き込みは有効な操作ではないため、これらは不変構造では発生しません。

また、私はと主張可変性が実際に必要なことはほとんどないされ、プログラマはちょうど考えて、それがあることかもしれない未来になります。たとえば、日付を変更しても意味がありません。むしろ、古い日付に基づいて新しい日付を作成します。これは安価な操作なので、パフォーマンスは考慮されません。

可変構造体は悪ではありません。

これらは、高パフォーマンスの状況では絶対に必要です。たとえば、キャッシュラインやガベージコレクションがボトルネックになる場合などです。

これらの完全に有効なユースケースでの不変の構造体の使用を「悪」とは呼びません。

C＃の構文では値型または参照型のメンバーのアクセスを区別するのに役立たないという点がわかります。そのため、私はすべて、可変構造よりも不変を強制する不変構造を好んでいます。

ただし、不変の構造体を単に「悪」としてラベル付けするのではなく、その言語を採用し、より有用で建設的な経験則を提唱することをお勧めします。

例：「構造体は値の型であり、デフォルトでコピーされます。コピーしたくない場合は参照が必要です」または 「最初に読み取り専用の構造体を使用してみてください」。

パブリックな可変フィールドまたはプロパティを持つ構造体は悪ではありません。

「プロパティ」を変更する構造体メソッド（プロパティセッターとは異なります）は、.netがそれらを変更しないメソッドと区別する手段を提供していないために、多少悪です。「this」を変更しない構造体メソッドは、読み取り専用の構造体であっても、防御的なコピーを必要とせずに呼び出すことができます。「this」を変更するメソッドは、読み取り専用の構造体ではまったく呼び出されません。.netは、「this」を変更しない構造体メソッドが読み取り専用の構造体で呼び出されるのを禁止したくないが、読み取り専用の構造体を変更できるようにしたくないので、構造的に読み取り構造をコピーします。コンテキストのみで、間違いなく両方の世界で最悪の事態に陥っています。

ただし、読み取り専用コンテキストでの自己変異メソッドの処理に関する問題にもかかわらず、可変構造体は、可変クラス型よりはるかに優れたセマンティクスを提供することがよくあります。次の3つのメソッドシグネチャを検討してください。

struct PointyStruct {public int x、y、z;};
クラスPointyClass {public int x、y、z;};

void Method1（PointyStruct foo）;
void Method2（ref PointyStruct foo）;
void Method3（PointyClass foo）;

それぞれの方法について、次の質問に答えてください。

1. メソッドが「安全でない」コードを使用しない場合、fooを変更する可能性がありますか？
2. メソッドが呼び出される前に 'foo'への外部参照が存在しない場合、外部参照が後に存在する可能性はありますか？

_答え：

質問1：
  Method1()：なし（意図クリア）
  Method2()：はい（意図クリア）
  Method3()：はい（不確かな意図）
質問2：
  Method1()：いいえ
  Method2()：いいえ（危険な場合を除き）
  Method3()：はい

Method1はfooを変更できず、参照を取得しません。Method2は、一時的なfooへの参照を取得します。これは、fooのフィールドを変更するまで何度でも、任意の順序で変更できますが、その参照を永続化することはできません。Method2が戻る前は、安全でないコードを使用していない限り、「foo」参照から作成された可能性のあるすべてのコピーが消えています。Method3は、Method2とは異なり、無差別に共有可能なfooへの参照を取得します。これを使用して何ができるかはわかりません。それはfooをまったく変更しないかもしれません、それはfooを変更してから戻るかもしれません。

構造の配列は素晴らしいセマンティクスを提供します。Rectangle型のRectArray [500]が与えられた場合、たとえば、要素123を要素456にコピーし、しばらくしてから要素123の幅を要素456に影響を与えずに555に設定する方法は明らかです。 "RectArray [432] = RectArray [321 ]; ...; RectArray [123] .Width = 555; "。RectangleがWidthと呼ばれる整数フィールドを持つ構造体であることを知っていると、上記のステートメントについて知っておく必要があるすべてのものがわかります。

ここで、RectClassがRectangleと同じフィールドを持つクラスであり、タイプRectClassのRectClassArray [500]で同じ操作を実行したいとします。おそらく、配列は、可変のRectClassオブジェクトへの初期化済みの不変の参照を500個保持することになっています。その場合、適切なコードは「RectClassArray [321] .SetBounds（RectClassArray [456]）; ...; RectClassArray [321] .X = 555;」のようになります。おそらく、配列は変更されないインスタンスを保持すると想定されているため、適切なコードは「RectClassArray [321] = RectClassArray [456]; ...; RectClassArray [321] = New RectClass（RectClassArray [321 ]）; RectClassArray [321] .X = 555; " 何をすべきかを知るためには、RectClassの両方についてより多くを知る必要があります（たとえば、コピーコンストラクター、コピー元メソッドなどをサポートしていますか）。）とアレイの使用目的。構造体を使用するほどきれいな場所はありません。

確かに、配列以外のコンテナークラスが構造体配列の明確なセマンティクスを提供するための良い方法はありません。コレクションに文字列などでインデックスを付ける場合、最善の方法は、インデックスの文字列、ジェネリックパラメーター、および渡されるデリゲートを受け入れるジェネリック "ActOnItem"メソッドを提供することです。ジェネリックパラメーターとコレクションアイテムの両方を参照する。それは構造体配列とほぼ同じセマンティクスを可能にしますが、vb.netとC＃の人々が素晴らしい構文を提供するように追求されない限り、コードは、それが合理的なパフォーマンスであっても不格好に見えるでしょう（一般的なパラメーターを渡すと静的デリゲートの使用を許可し、一時クラスインスタンスを作成する必要がなくなります）。

個人的に、私は憎しみのあるエリック・リッペルトらに腹を立てています。変更可能な値の型に関する説明。それらは、至る所で使用されている無差別参照タイプよりもはるかに明確なセマンティクスを提供します。.netの値タイプのサポートにはいくつかの制限がありますが、変更可能な値タイプが他の種類のエンティティよりも適している場合が多くあります。

値型は基本的に不変の概念を表します。Fx、整数、ベクトルなどの数学的な値を持っていて、それを変更できるようにすることは意味がありません。それは、値の意味を再定義するようなものです。値タイプを変更する代わりに、別の一意の値を割り当てる方が理にかなっています。値の型がそのプロパティのすべての値を比較することによって比較されるという事実について考えてください。重要なのは、プロパティが同じであれば、その値の同じ普遍的な表現になるということです。

Konradが言及しているように、値はその一意の時点を表し、状態やコンテキストに依存する時間オブジェクトのインスタンスではないため、日付を変更しても意味がありません。

これがあなたにとって意味のあることだと思います。確かに、実際の詳細ではなく、値タイプを使用してキャプチャしようとするコンセプトについてです。

プログラマーの観点から予測できない動作を引き起こす可能性のある他のいくつかのコーナーケースがあります。

不変の値タイプと読み取り専用フィールド

    // Simple mutable structure. 
    // Method IncrementI mutates current state.
    struct Mutable
    {
        public Mutable(int i) : this() 
        {
            I = i;
        }

        public void IncrementI() { I++; }

        public int I { get; private set; }
    }

    // Simple class that contains Mutable structure
    // as readonly field
    class SomeClass 
    {
        public readonly Mutable mutable = new Mutable(5);
    }

    // Simple class that contains Mutable structure
    // as ordinary (non-readonly) field
    class AnotherClass 
    {
        public Mutable mutable = new Mutable(5);
    }

    class Program
    {
        void Main()
        {
            // Case 1. Mutable readonly field
            var someClass = new SomeClass();
            someClass.mutable.IncrementI();
            // still 5, not 6, because SomeClass.mutable field is readonly
            // and compiler creates temporary copy every time when you trying to
            // access this field
            Console.WriteLine(someClass.mutable.I);

            // Case 2. Mutable ordinary field
            var anotherClass = new AnotherClass();
            anotherClass.mutable.IncrementI();

            // Prints 6, because AnotherClass.mutable field is not readonly
            Console.WriteLine(anotherClass.mutable.I);
        }
    }

可変値型と配列

Mutable構造体の配列がありIncrementI、その配列の最初の要素のメソッドを呼び出しているとします。この電話からどのような行動を期待していますか？配列の値を変更する必要がありますか、それともコピーのみですか？

    Mutable[] arrayOfMutables = new Mutable[1];
    arrayOfMutables[0] = new Mutable(5);

    // Now we actually accessing reference to the first element
    // without making any additional copy
    arrayOfMutables[0].IncrementI();

    // Prints 6!!
    Console.WriteLine(arrayOfMutables[0].I);

    // Every array implements IList<T> interface
    IList<Mutable> listOfMutables = arrayOfMutables;

    // But accessing values through this interface lead
    // to different behavior: IList indexer returns a copy
    // instead of an managed reference
    listOfMutables[0].IncrementI(); // Should change I to 7

    // Nope! we still have 6, because previous line of code
    // mutate a copy instead of a list value
    Console.WriteLine(listOfMutables[0].I);

したがって、変更可能な構造体は、あなたとチームの他のメンバーがあなたが何をしているかを明確に理解している限り、悪ではありません。しかし、プログラムの動作が予想とは異なるコーナーケースが多すぎて、微妙な生成やエラーの理解が困難になる可能性があります。

C / C ++のような言語でプログラミングしたことがある場合は、構造体を可変として使用することをお勧めします。単にrefで渡してください。問題が発生することはありません。私が見つけた唯一の問題は、C＃コンパイラの制限であり、場合によっては、愚かなことで、構造体がC＃クラスの一部である場合のように、コピーの代わりに構造体への参照を使用するように強制できないことがあります）。

したがって、変更可能な構造体は悪ではなく、C＃によって悪になっています。私は常にC ++で可変構造体を使用しており、それらは非常に便利で直感的です。対照的に、C＃では、構造体がオブジェクトを処理する方法が原因で、構造体をクラスのメンバーとして完全に破棄するようになりました。彼らの利便性は私たちのものを犠牲にしました。

構造体が意図されているもの（C＃、Visual Basic 6、Pascal / Delphi、C ++構造体タイプ（またはクラス）がポインターとして使用されていない場合）に固執すると、構造体は複合変数にすぎないことがわかります。つまり、共通の名前（メンバーを参照するレコード変数）の下で、それらを変数のパックされたセットとして扱います。

それがOOPに深く慣れている多くの人々を混乱させることは知っていますが、それが正しく使用された場合、そのようなものが本質的に悪であると言うのに十分な理由ではありません。一部の構造は意図したとおりに不変です（これはPythonの場合ですnamedtuple）が、考慮すべきもう1つのパラダイムです。

はい：構造体には大量のメモリが含まれますが、次のようにすると、メモリが正確に増えるわけではありません。

point.x = point.x + 1

に比べ：

point = Point(point.x + 1, point.y)

メモリ消費量は、少なくとも同じか、または不変の場合でもそれ以上になります（その場合は、現在のスタックでは、言語によっては一時的なものです）。

しかし、最後に、構造はオブジェクトではなく構造です。POOでは、オブジェクトの主要なプロパティはそれらのIDであり、ほとんどの場合、それはメモリアドレス以下です。Structはデータ構造を表しており（適切なオブジェクトではないため、IDはありません）、データを変更できます。他の言語では、（Pascalの場合のようにstructではなく）recordが単語であり、同じ目的を保持します。ファイルから読み取られ、変更され、ファイルにダンプされることを目的とするデータレコード変数（メイン多くの言語では、レコードのデータ配置を定義することもできますが、適切に呼び出されたオブジェクトの場合は必ずしもそうではありません）。

良い例が欲しいですか？構造体は、ファイルを簡単に読み取るために使用されます。Pythonにはこのライブラリがあります。オブジェクト指向であり、構造体をサポートしていないため、Pythonは別の方法で実装する必要があり、やや醜いためです。構造体を実装する言語には、その機能が組み込まれています。PascalやCなどの言語で、適切な構造体を使用してビットマップヘッダーを読み取ってみてください。これは簡単です（構造体が適切に構築および配置されている場合、Pascalでは、レコードベースのアクセスではなく、任意のバイナリデータを読み取る関数を使用します）。したがって、ファイルと直接（ローカル）メモリアクセスの場合、構造体はオブジェクトよりも優れています。今日については、JSONとXMLに慣れているため、バイナリファイルの使用（および副作用として構造体の使用）を忘れています。しかし、はい：それらは存在し、目的があります。

彼らは悪ではありません。適切な目的で使用してください。

ハンマーの観点から考えると、ネジを釘として扱い、ネジを壁に突っ込むのは難しく、それはネジのせいであり、邪悪なものになります。

1,000,000の構造体の配列があるとします。bid_price、offer_price（おそらく小数）などの要素を持つエクイティを表す各構造体は、C＃/ VBによって作成されます。

他のネイティブコードスレッドが配列に同時にアクセスできるように、アンマネージヒープに割り当てられたメモリのブロックに配列が作成されることを想像してください（おそらくいくつかの高パフォーマンスコードが計算を実行しています）。

C＃/ VBコードが価格変更の市場フィードをリッスンしていると想像してみてください。そのコードは、配列の一部の要素（セキュリティ）にアクセスし、一部の価格フィールドを変更する必要がある場合があります。

これが1秒あたり数万回または数十万回行われていると想像してください。

事実に直面してみましょう。この場合、これらの構造体を変更可能にしたいのですが、他のネイティブコードによって共有されているため、これらの構造体を変更する必要があるため、コピーを作成しても役に立ちません。これらの速度で約120バイトの構造体のコピーを作成することは、特に更新が実際に1バイトまたは2バイトだけに影響を与える可能性がある場合には、面倒なので、そうする必要があります。

ヒューゴ

何かが変異する可能性があるとき、それはアイデンティティの感覚を得ます。

struct Person {
    public string name; // mutable
    public Point position = new Point(0, 0); // mutable

    public Person(string name, Point position) { ... }
}

Person eric = new Person("Eric Lippert", new Point(4, 2));

Personは変更可能であるため、Ericのクローンを作成し、クローンを移動して元のを破壊するよりも、Ericの位置を変更することを考える方が自然です。どちらの操作でもの内容の変更は成功しますがeric.position、1つは他よりも直感的です。同様に、Ericを変更する方法について（参照として）Ericを渡す方が直感的です。メソッドをエリックのクローンに与えることは、ほとんど常に驚くべきことです。変異を起こしたい人Personは、参照を要求することを忘れないでくださいPerson。そうしないと、間違ったことが行われます。

型を不変にすると、問題はなくなります。変更できない場合でもeric、を受け取ったのericかクローンを受け取ったのかは関係ありませんeric。より一般的には、次のいずれかのメンバーで監視可能な状態がすべて保持されている場合、型は値で渡しても安全です。

• 不変
• 参照タイプ
• 値渡ししても安全

これらの条件が満たされると、浅いコピーでも受信者が元のデータを変更できるため、可変値型は参照型のように動作します。

イミュータブルの直感性は、Person何をしようとしているかに依存します。人に関する一連のデータをPerson表すだけの場合、直感的なものはありません。変数は、オブジェクトではなく、実際に抽象的な値を表します。（その場合は、名前をに変更する方がおそらく適切です。）が実際に個人をモデル化している場合、クローンを絶えず作成および移動するという考えは、変更していると考える落とし穴を回避したとしても、ばかげています。オリジナル。その場合は、単に参照型（つまり、クラス）を作成する方が自然でしょう。PersonPersonDataPersonPerson

確かに、関数型プログラミングはすべてを不変にすることには利点があります（だれもeric彼への参照をこっそり保持して変更することはできません）。コード。

構造体（およびC＃とも関係ありません）とは何の関係もありませんが、Javaでは、たとえばハッシュマップのキーなどの可変オブジェクトに問題が発生する可能性があります。マップに追加した後でそれらを変更し、そのハッシュコードを変更すると、悪事が発生する可能性があります。

個人的にコードを見ると、以下はかなり不格好に見えます。

data.value.set（data.value.get（）+ 1）;

単にではなく

data.value ++; またはdata.value = data.value + 1;

データのカプセル化は、クラスを渡し、値が制御された方法で変更されるようにする場合に便利です。ただし、パブリックセットを使用して、渡されたものに値を設定するだけの関数を取得する場合、パブリックデータ構造体を単に渡すだけの場合よりも、どのように改善されますか？

クラス内にプライベート構造を作成するとき、その構造を作成して、変数のセットを1つのグループに編成しました。その構造のコピーを取得して新しいインスタンスを作成するのではなく、クラススコープ内でその構造を変更できるようにしたいと思います。

私にとってこれは、パブリック変数の編成に使用される構造の有効な使用を妨げます。アクセス制御が必要な場合は、クラスを使用します。

Eric Lippert氏の例にはいくつかの問題があります。構造体がコピーされる点と、注意しないとそれがどのように問題になるかを説明するために工夫されています。例を見ると、それはプログラミングの習慣が悪い結果であり、構造体やクラスの問題ではないことがわかります。

1. 構造体はパブリックメンバーのみを想定しており、カプセル化は必要ありません。もしそうなら、それは本当にタイプ/クラスであるべきです。同じことを言うのに2つの構成要素は必要ありません。

2. 構造体を囲むクラスがある場合は、クラスのメソッドを呼び出してメンバーの構造体を変更します。これは、私が良いプログラミング習慣として行うことです。

適切な実装は次のようになります。

struct Mutable {
public int x;
}

class Test {
    private Mutable m = new Mutable();
    public int mutate()
    { 
        m.x = m.x + 1;
        return m.x;
    }
  }
  static void Main(string[] args) {
        Test t = new Test();
        System.Console.WriteLine(t.mutate());
        System.Console.WriteLine(t.mutate());
        System.Console.WriteLine(t.mutate());
    }

構造体自体の問題ではなく、プログラミングの習慣の問題のようです。構造体は変更可能であることが想定されています。つまり、それはアイデアと意図です。

変更の結果、期待どおりに動作します。

1 2 3任意のキーを押して続行します。。。

可変データには多くの利点と欠点があります。100万ドルの欠点はエイリアシングです。同じ値が複数の場所で使用されており、そのうちの1つが変更した場合、その値を使用している他の場所に魔法のように変更されたように見えます。これは、競合状態に関連しますが、同一ではありません。

100万ドルの利点は、モジュール性です。可変状態を使用すると、変更する情報を、その情報を知る必要のないコードから隠すことができます。

Art of the Interpreterでは、これらのトレードオフについて詳細に説明し、いくつかの例を示します。

正しく使えば悪だとは思いません。量産コードには入れませんが、構造化ユニットテストのモックのように、構造体の寿命が比較的短いものを使用します。

Ericの例を使用して、おそらくそのEricの2番目のインスタンスを作成しますが、それはテストの性質（つまり、複製してから変更）であるため、調整を行います。テストの比較としてEric2を使用する予定がない限り、テストスクリプトの残りの部分にEric2を使用しているだけでは、Ericの最初のインスタンスがどうなるかは問題ではありません。

これは、特定のオブジェクト（構造体のポイント）を浅く定義するレガシーコードをテストまたは変更する場合に最も役立ちますが、不変の構造体を使用することで、煩わしい使用を防ぎます。