Go で Nil スライスに追加すると予期しない容量拡張が発生するのはなぜですか?

Nil スライスと容量拡張

Go の nil スライスに対する追加操作では、容量の動作について疑問が生じます。次のシナリオを考えてみましょう:

var s1 []int // len(s1) == 0, cap(s1) == 0
s2 := append(s1, 1) // len(s2) == 1, cap(s2) == 2

最初は空だったスライス s1 に 1 つの要素を追加した後、s2 の容量が予期せず 2 に増加しました。

なぜ拡張するのですか?

Go のアロケーターは、パフォーマンスを最適化するために要求された以上の容量を提供することがよくあります。これにより、追加の割り当てやコピー操作の頻度が減ります。 Capacity は、別の割り当てが必要になる前に利用可能なバッファ スペースを表します。

この場合、1 つの要素を追加するには、最小容量 1 のバッファが必要です。ただし、Go は、2 などのより大きな容量のバッファを割り当てる場合があります。この例では、

容量と長さ

容量は次のものとは異なることに注意することが重要です。 長さ。長さはスライス内の実際の要素の数を指し、容量は新しい割り当てが必要になるまでにスライスが保持できる要素の最大数を示します。

長さを超えたアクセス

スライスは基礎となる配列を参照し、そのインデックスの上限がその容量として定義されます。したがって、スライス内の長さを超える要素へのアクセスは許容されますが、論理エラーや実行時パニックを引き起こす可能性があるアンチパターンです。

fmt.Printf() および Zero Values

nil スライス s1 を印刷すると、空の文字列 [] として正しくレンダリングされます。ただし、展開された非 nil スライスを印刷すると、最後に予期しないゼロ値が表示される場合があります。これらの値は実際のスライス データの一部ではありませんが、スライスの容量によりインデックス作成を通じてアクセスできます。出力されたスライスを慎重に解釈し、長さを超える要素にアクセスしないようにすることが重要です。

結論として、Go の nil スライスは追加操作によって容量を拡張してパフォーマンスを向上させることができます。ただし、長さと容量を区別し、スライス要素にアクセスする際に予期しない容量の動作に依存しないようにすることが重要です。

以上がGo で Nil スライスに追加すると予期しない容量拡張が発生するのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。