C および C では、構造体内では配列の割り当てが許可されるのに、スタンドアロン配列では許可されないのはなぜですか?

C および C での配列の割り当て : 構造体と哲学的洞察の例外

C および C では、例に示すように、配列を直接割り当てることは禁止されていますによって以下:

int num1[3] = {1,2,3};
int num2[3];
num2 = num1; // Error: invalid array assignment

ただし、配列が構造体のコンポーネントである場合は例外が発生します:

struct myStruct { int num[3]; };
struct myStruct struct1 = {{1,2,3}};
struct myStruct struct2;
struct2 = struct1;

この場合、構造体内の配列はメンバーごとに割り当てることができます。これにより、メンバーごとの配列割り当てが構造体に対してサポートされているのに、一般的にはサポートされていないのはなぜかという疑問が生じます。

進化の理論的根拠

配列の動作の起源は歴史的発展にあります。 B と BCPL では、配列は暗黙的に型なしのポインターとして扱われました。 B の構造体には、配列に対応するための特別な処理が必要でした。これにより、構造体内の配列がコンパイラで追跡されるエンティティとして処理されるようになりました。

これにより、配列の再評価が必要になるため、一般に配列の代入を禁止する必要がありました。配列のベースポインタ。互換性を維持するために、構造体内の配列であっても配列の代入は禁止されました。

構造体の代入と副作用

構造体の代入が C で導入されたとき、構造体の代入は構造体の生メモリの単純な memcpy。この代入動作は、誤って構造体内の配列にも拡張されてしまいました。

構造体の代入はすでに言語の一部であったため、配列の代入動作を変更しようとすると、既存のコードが壊れる可能性があります。したがって、意図しないものであっても、構造体内の配列代入は例外として残ります。

哲学的観点

言語設計の観点からは、配列は、それとは異なり、構造体は決して一級市民として意図されたものではありません。ポインタとしての機能は、潜在的な人間工学的利点よりも下位互換性を優先しました。

さらに、一般的な配列割り当てを導入すると、誤ってポインタを作成したりメモリ リークが発生したりする可能性など、複雑さが生じます。

結論

構造体内でのメンバーごとの配列代入のサポートは、以下に由来する歴史的な成果物です。 C の初期の進化。互換性の問題のために存続しており、単純さと後方互換性を優先するという言語の基本的な設計哲学を思い出させる役割を果たしています。

以上がC および C では、構造体内では配列の割り当てが許可されるのに、スタンドアロン配列では許可されないのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。