saccharine
saccharine

Reputation: 904

go tour when to not use pointer to struct literal in a variable

Per the Go tour page 28 and page 53

They show a variable that is a pointer to a struct literal. Why is this not the default behavior? I'm unfamiliar with C, so it's hard to wrap my head around it. The only time I can see when it might not be more beneficial to use a pointer is when the struct literal is unique, and won't be in use for the rest program and so you would want it to be garbage collected as soon as possible. I'm not even sure if a modern language like Go even works that way.

My question is this. When should I assign a pointer to a struct literal to a variable, and when should I assign the struct literal itself?

Thanks.

Upvotes: 12

Views: 2583

Answers (2)

Caleb
Caleb

Reputation: 9468

You're probably right that most of the time you want pointers, but personally I find the need for an explicit pointer refreshing. It makes it so there's no difference between int and MyStruct. They behave the same way.

If you compare this to C# - a language which implements what you are suggesting - I find it confusing that the semantics of this:

static void SomeFunction(Point p)
{
    p.x = 1;
}
static void Main()
{
    Point p = new Point();
    SomeFunction(p);
    // what is p.x?
}

Depend on whether or not Point is defined as a class or a struct.

Upvotes: 2

Denys Séguret
Denys Séguret

Reputation: 382434

Using a pointer instead of just a struct literal is helpful when

  • the struct is big and you pass it around
  • you want to share it, that is that all modifications affect your struct instead of affecting a copy

In other cases, it's fine to simply use the struct literal. For a small struct, you can think about the question just as using an int or an *int : most of the times the int is fine but sometimes you pass a pointer so that the receiver can modify your int variable.

In the Go tour exercises you link to, the Vertex struct is small and has about the same semantic than any number. In my opinion it would have been fine to use it as struct directly and to define the Scaled function in #53 like this :

func (v Vertex) Scaled(f float64) Vertex {
    v.X = v.X * f
    v.Y = v.Y * f
    return v
}

because having

v2 := v1.Scaled(5)

would create a new vertex just like

var f2 float32 = f1 * 5

creates a new float.

This is similar to how is handled the standard Time struct (defined here), which is usually kept in variables of type Time and not *Time.

But there is no definite rule and, depending on the use, I could very well have kept both Scale and Scaled.

Upvotes: 14

Related Questions