When is a pointer idiomatic?

Question

I come from languages which don't have explicit pointers, so I don't really understand the point of their existence (no pun intended).

The problem is that I have no idea, most of the time, why I am passing a pointer to a function. I do understand that when you pass in a pointer, modifications to the variable are done to the value everywhere, but what's the point? Why not just modify the value and return the result?

For example, http.HandlerFunc is a function that receives http.ResponseWriter and *http.Request as arguments. I have read that interfaces are in fact pointers (is that right?), but what I'm not getting is, why?

Why am I getting a pointer to a writer? I'm not modifying it, I'm merely writing to it. And, why am I getting a pointer to a request? I am doing stuff like request.FormValue().

What I'm trying to determine here, through these examples, is the answer to the question, "when do I need to pass in a pointer?"

The way I do it right now is to write my code, try to compile it, fix the errors that say I must pass in a pointer by adding an ampersand and asterisk, until the errors pass. However, I feel this half-understood concept of pointers is going to bite me in the backside some day very soon.

Answer 1

Pointers are really easy concept when you are just understand how they are works, but before understanding it really looks hard and annoying stuff, especially in C. There are pointer arithmetic, pointer which points a pointer etc.

Anyway, you haven't to use pointers, if your library doesn't force you to use, but passing variables, data structures around the functions may copy all the things into another memory section because of the function scope.

In most of the languages values are passes by literals. It means when you pass a variable to a function or class, it probably copy it.

More memory consumption, also needs CPU time to copy items. Not good for complexity.

On the other hand some languages like PHP has some automation, like copy on write algorithm when you pass a parameter to a function it passes by reference, it passes just memory address to function until function attempts to write to this variable, in that time it just copies the variable.

But automation also brings some costs. The real point here cost Go tries to be fast as possible less automation more user control but also tries to be safe and simple. Not like C, C++ it doesn't make you feel ashamed.

In your example http.ResponseWriter when you pass this to the any function by its memory reference(as a pointer) you write things to it inside this function, it just directly writes to it, there is no special algorithm or check if there is no type mismatch etc. there may some check like garbage collector but It really brings advantages than it costs.

Also in PHP, Java objects are passes by their references but the language just hides this verbosity.

I have read that interfaces are in fact pointers

Not exactly, Interface{} Is a base type in Go so every type implements interface type, in this point of view it is just a type so there is no meaning to call as a pointer. It gives you a dynamism, for example : if you read from a source which the data has not structured and inconsistent, structure can change any time e.g XML or JSON source. Just use Interface! you already know every type's ancestor is the Interface it will just handle underlying structure/type of data in runtime.

But also you can use Interface term to define an interface (like java, c#, php etc.) and put implementation methods. When any of the struct which satisfies these methods. It naturally implements the interface. This implementation design called as Duck Typing please read for further information https://en.wikipedia.org/wiki/Duck_typing

Answer 2

A pointer is, as the name suggests, a variable that points to a place in memory.

You use it when copying the entire value of the object is unreasonable for some reason. This can either be because an object is so large that copying it would be slow, so you want to just pass a small pointer to the object and use the same object in memory (probably the reason http.Request is a pointer), or because you need to modify an existing reference to an object that other places in your code might already have a reference to. You can look into the code for net/http here to see why. (In fact, for any Go standard library the code is a open if you want to look into why or how something is done a certain way.)

But that's kind of irrelevant, because as a user, the reason you're passing a pointer is because the function is defined to take a pointer as a parameter. What reason the programmer who wrote the library decided to use a pointer is doesn't matter. You can either look up the go doc, or you can do what you're doing, and just pass a value, and if the compiler complains fix it.

Answer 3

You can think of a pointer as a value that points to the memory address of an object. Pointers are small (say 8 bytes) compared to most data structures.

A lot of times you will get a pointer to an object because it is much faster to pass those 8 bytes than to create a copy of the entire object that you want to pass.

In the case of a Request object it would be very expensive to create a copy of everything under the request (the payload, headers, and whatnot) compared to just passing a pointer that has access to the original data.