Goでの構造体のスタックとヒープの割り当て、およびガベージコレクションとの関係
私はGoを始めたばかりで、自動変数がスタックに存在し、割り当てられたメモリがヒープに存在するCスタイルのスタックベースのプログラミングと、Pythonスタイルのスタックベースのプログラミングが、スタック上に存在するものだけが、ヒープ上のオブジェクトへの参照/ポインターです。 私の知る限り、次の2つの関数は同じ出力を提供します。 func myFunction() (*MyStructType, error) { var chunk *MyStructType = new(HeaderChunk) ... return chunk, nil } func myFunction() (*MyStructType, error) { var chunk MyStructType ... return &chunk, nil } つまり、新しい構造体を割り当ててそれを返します。 それをCで書いた場合、最初のオブジェクトはヒープにオブジェクトを配置し、2番目のオブジェクトはスタックにオブジェクトを配置します。1つ目はヒープへのポインターを返し、2つ目はスタックへのポインターを返します。これは、関数が戻ったときまでに蒸発していたものであり、これは悪いことです。 Python（またはC＃を除く他の多くの現代言語）で記述した場合、例2は不可能でした。 Goガベージは両方の値を収集するので、上記の両方の形式で問題ありません。 引用するには： Cとは異なり、ローカル変数のアドレスを返すことはまったく問題ありません。変数に関連付けられたストレージは、関数が戻った後も存続します。実際、複合リテラルのアドレスを取得すると、評価されるたびに新しいインスタンスが割り当てられるため、これらの最後の2行を組み合わせることができます。 http://golang.org/doc/effective_go.html#functions しかし、それはいくつかの質問を提起します。 1-例1では、構造体はヒープで宣言されています。例2はどうですか？それはCの場合と同じようにスタックで宣言されていますか、それともヒープに移動しますか？ 2-例2がスタックで宣言されている場合、関数が戻った後、例2はどのように利用可能のままですか？ 3-例2が実際にヒープで宣言されている場合、構造体は参照ではなく値で渡されるのはなぜですか。この場合のポインタのポイントは何ですか？