这种“模式”背后的动机是什么？

Question

I'm a bit confused when I see code such as:

bigBox := &BigBox{}
bigBox.BubbleGumsCount = 4          // correct...
bigBox.SmallBox.AnyMagicItem = true // also correct

Why, or when, would I want to do bigBox := &BigBox{} instead of bigBox := BigBox{} ? Is it more efficient in some way?

Code sample was taken from here.

Sample no.2:

package main

import "fmt"

type Ints struct {
  x int
  y int
}

func build_struct() Ints {
  return Ints{0,0}
}

func build_pstruct() *Ints {
  return &Ints{0,0}
}

func main() {
  fmt.Println(build_struct())
  fmt.Println(build_pstruct())
}

Sample no. 3: ( why would I go with &BigBox in this example, and not with BigBox as a struct directly ? )

func main() {
  bigBox := &BigBox{}
  bigBox.BubbleGumsCount = 4 
  fmt.Println(bigBox.BubbleGumsCount)
}

Is there ever a reason to call build_pstruct instead of the the build_struct variant? Isn't that why we have the GC?

Answer 1

I figured out one motivation for this kind of code: avoidance of "struct copying by accident".

---

If you use a struct variable to hold the newly created struct:

bigBox := BigBox{}

you may copy the struct by accident like this

myBox := bigBox // Where you just want a refence of bigBox.
myBox.BubbleGumsCount = 4

or like this

changeBoxColorToRed(bigBox)

where changeBoxColorToRed is

// It makes a copy of entire struct as parameter. 
func changeBoxColorToRed(box bigBox){
    // !!!! This function is buggy. It won't work as expected !!!
    // Please see the fix at the end.
    box.Color=red
}

---

But if you use a struct pointer:

bigBox := &BigBox{}

there will be no copying in

myBox := bigBox

and

changeBoxColorToRed(bigBox)

will fail to compile, giving you a chance to rethink the design of changeBoxColorToRed. The fix is obvious:

func changeBoxColorToRed(box *bigBox){
    box.Color=red
}

The new version of changeBoxColorToRed does not copy the entire struct and works correctly.