Jestem nowym użytkownikiem Go i doświadczam niewielkiego dysonansu kongijnego między programowaniem opartym na stosie w stylu C, gdzie zmienne automatyczne działają na stosie, a przydzielona pamięć żyje na sterty i programowaniu opartym na stosie w stylu Pythona, gdzie Jedyną rzeczą, która żyje na stosie, są odwołania / wskaźniki do obiektów na stercie.

O ile wiem, dwie następujące funkcje dają ten sam wynik:

func myFunction() (*MyStructType, error) {
    var chunk *MyStructType = new(HeaderChunk)

    ...

    return chunk, nil
}


func myFunction() (*MyStructType, error) {
    var chunk MyStructType

    ...

    return &chunk, nil
}

tj. przydziel nową strukturę i zwróć ją.

Gdybym napisał, że w C, pierwszy umieściłby obiekt na stercie, a drugi umieściłby go na stosie. Pierwszy zwróci wskaźnik do sterty, drugi zwróci wskaźnik do stosu, który odparowałby do czasu powrotu funkcji, co byłoby Bad Thing.

Gdybym to napisał w Pythonie (lub wielu innych współczesnych językach z wyjątkiem C #), przykład 2 nie byłby możliwy.

Dostaję, że Go garbage zbiera obie wartości, więc obie powyższe formy są w porządku.

Cytować:

Zauważ, że w przeciwieństwie do C, zwracanie adresu zmiennej lokalnej jest całkowicie OK; pamięć powiązana ze zmienną przetrwa po zwróceniu funkcji. W rzeczywistości, przyjęcie adresu literału złożonego przydziela nową instancję za każdym razem, gdy jest ona oceniana, więc możemy połączyć te dwie ostatnie linie.

http://golang.org/doc/effective_go.html#functions

Ale rodzi to kilka pytań.

1 - W przykładzie 1 struktura jest zadeklarowana na stercie. A co z przykładem 2? Czy jest to zadeklarowane na stosie w taki sam sposób, w jaki byłby w C, czy też na stosie?

2 - Jeśli przykład 2 jest zadeklarowany na stosie, w jaki sposób pozostaje dostępny po zwróceniu funkcji?

3 - Jeśli przykład 2 jest faktycznie zadeklarowany na stercie, jak to się dzieje, że struktury są przekazywane przez wartość, a nie przez odniesienie? Jaki jest sens wskaźników w tym przypadku?