A reader recently encountered a new problem with struct that he could not solve.
Examples of Doubt
The example 1 it gives is as follows.
What do you think the output will be?
The output is: false.
With a little more modification, Example 2 is as follows.
The output is: true.
His question is “Why does the first return false and the second return true, and what causes it?
Further refinement of this example yields the following minimal example.
The result of the first code is false and the second one is true, and you can see that the memory address points to exactly the same, which means that the change in the memory pointing of the variable after the output is ruled out as the cause.
Looking further, it seems to be caused by the
fmt.Print method, but an output method in a standard library that causes this strange problem?
Developers who have dealt with this problem before, or have seen the source code. You may be able to quickly realize that the output leading to this is the result of escape analysis.
Let’s perform an escape analysis on the example.
The analysis shows that variables a and b are allocated on the stack, while variables c and d are allocated on the heap.
The key reason for this is that the
fmt.Println method is called, which involves a large number of reflection-related method calls inside the method, causing escape behavior, i.e., allocation to the heap.
Why comparing results after an escape is equal
Focus on the first detail, which is “Why would the two empty structs be equal after the escape?” .
Here it is mainly related to an optimization detail of Go runtime, as follows.
The variable zerobase is the base address for all 0-byte allocations. Further, the empty (0-byte) ones will point to the zerobase address after the escape analysis.
So the empty struct essentially points to zerobase after the escape, and the comparison between the two is equal and returns true.
Why the comparison results are not equal in the case of non-escapement
Focus on the second detail, which is “Why are the two empty struct comparisons not equal before the escape?” .
From the Go spec, this is a deliberate design by the Go team, which does not want people to rely on this one as a basis for judgment. As follows.
This is an intentional language choice to give implementations flexibility in how they handle pointers to zero-sized objects. If every pointer to a zero-sized object were required to be different, then each allocation of a zero-sized object would have to allocate at least one byte. If every pointer to a zero-sized object were required to be the same, it would be different to handle taking the address of a zero-sized field within a larger struct.
And also said a very classic words
Pointers to distinct zero-size variables may or may not be equal.
Also the scenarios in which empty structs are used in practice are relatively rare and common.
- Set the context, which is used when passing as key.
- Set empty struct for temporary use in business scenarios.
But most of the business scenarios will also change as the business evolves. Suppose there is a long-ago Go code that relies on the direct judgment of an empty struct, wouldn’t it be an accident?
Not directly dependent
So this action by the Go team is worth thinking about, as is the randomness of the Go map, to avoid everyone’s direct reliance on this kind of logic.
In the scenario where there is no escape, the comparison action of two empty structs that you think are really being compared. In fact it has been directly optimized away to false in the code optimization phase.
So, although it looks like == is doing the comparison in the code, the result is actually a == b when it turns out to be false, and there is no need to compare.
Don’t you think that’s great?
did not escape making him equal
As you can see, the result of both comparisons is now true.
In today’s article, we further complement the comparison scenario for empty structures (structs) in the Go language. After these two articles, you will have a better understanding of why Go structs are called both comparable and non-comparable.
And the main reason for the wonders of empty structure comparison is as follows.
- If escaping to the heap, the empty struct is allocated by default with the runtime.zerobase variable, a 0-byte base address specifically for allocation to the heap. So two empty structs, both runtime.zeroobase, will be true when compared.
- If no escape occurs, they are also allocated to the stack. In the code optimization phase of the Go compiler, this is optimized to return false directly, not in the traditional sense of actually comparing.