今朝、Visual Studio 2005でprivate、クラスに新しいメンバー変数を追加しようとしましたが、それがあらゆる種類の奇妙なセグメンテーション違反などを引き起こしていることがわかりました。デバッグモードに入ると、デバッガーが新しいメンバー変数を認識していなかったため、奇妙な動作が発生していました。
プログラムを再び動作させるために（そしてデバッガーに作成した新しいメンバー変数を表示させるために）、「すべてを再構築」する必要がありました。 なぜすべてを再構築する必要があったのですか？なぜ通常のビルドを行うだけでは不十分だったのですか？
私はすでに問題を解決しましたが、ビルドプロセスをよりよく理解することが将来私に役立つと感じています。他に必要な情報があれば教えてください。
前もって感謝します！
クラスのメンバーを追加または削除すると、オブジェクトのメモリレイアウトが変更されます。再コンパイルしないと、ODRルールに違反していることになり、セグメンテーション違反はその影響にすぎません。
その理由については、古いコードが古いサイズのメモリを取得し、そのオブジェクトを（新しいメンバーなしで）新しいコードに渡して、割り当てられたメモリの終わりを超えて新しい変数にアクセスする可能性があります。アクセス指定子はまったく影響を与えないことに注意してください。プライベートの場合は、フィールドにアクセスするクラスメンバー関数である可能性があります。
フィールドを最後に追加せず、オブジェクトの中央に追加した場合、コンパイラによって上位メモリアドレスに配置されたフィールドにアクセスするときに同じ効果が見られます。
すべて再構築機能を使用する必要があるという事実は、プロジェクトの依存関係が正しく構成されていないことを示しているため、できるだけ早く修正する必要があります。適切な依存関係があると、コンパイラは必要に応じて再構築を強制され、無駄なデバッグ時間が少なくなります。
明白な答えの1つは、「Visual Studioが壊れており、依存関係を正しく処理しないため」です。ただし、実際には、そのステートメントを作成するのに十分な情報を提供してくれたとは思いません（Visual Studioは単純なケースを正しく理解しています）。
メンバー（privateまたはpublic、それは問題ではありません）、特にデータメンバーだけでなく、仮想関数も追加すると、メモリ内のクラスの物理レイアウトが変更されます。その物理レイアウトに依存するすべてのコードを再コンパイルする必要があります。通常、ビルドシステムはこれを自動的に処理しますが、makefileの破損、またはシステムのバグは、そうでないことを簡単に意味する可能性があります。（正解は、再構築/クリーンアップを呼び出すことではなく、ビルドシステムの問題を修正することです。）