3 ms·
> This seems to be a persistent source of confusion. Why? It is the same as in C. #include <stdio.h> #include <stdlib.h> struct slice { i
by 9rx 11mo ago
> This seems to be a persistent source of confusion.
Why? It is the same as in C.
#include <stdio.h>
#include <stdlib.h>
struct slice {
int *data;
size_t len;
size_t cap;
};
struct slice readLogsFromPartition() {
int *data = malloc(2);
data[0] = 1;
data[1] = 2;
return (struct slice){ data, 2, 2 };
}
int main() {
struct slice s = readLogsFromPartition();
for (int i = 0; i < s.len; i++) {
printf("%d\n", s.data[i]);
}
free(s.data);
}
- simiones 11mo agoThe point the GP was making was that the following Go snippet: func foo() { x := []int { 1 } //SNIP } Could translate to C either as: void foo() { int* x = malloc(1 * sizeof(int)); x[0] = 1; //... } Or as void foo() { int data[1] = {1}; int *x = data; //... } Depending on the content of //SNIP. However, some people think that the semantics can also match the semantics of the second version in C - when in fact the semantics of the Go code always match the first version, even when the actual implementation is the second version.
- 9rx 11mo agoThe semantics are clearly defined as being the same as the C code I posted earlier. Why would one try to complicate the situation by thinking that it would somehow magically change sometimes?
- simiones 11mo agoBecause people hear that Go supports value types and so is more efficient than Java because it can allocate on the stack*, and so they start thinking that they need to manage the stack. * Of course, in reality, Java also does escape analysis to allocate on the stack, though it's less likely to happen because of the lack of value types.
- 9rx 11mo agoI don't see the difficulty here. The slice is to be thought of as value type, as demonstrated in the C version. Just like in C, you can return it from a function without the heap because it is copied.
- foldr 11mo agoWhat confuses people is int *foo(void) { int x = 99; return &x; // bad idea } vs. func foo() *int { x := 99 return &x // fine } They think that Go, like C, will allocate x on the stack, and that returning a pointer to the value will therefore be invalid. (Pedants: I'm aware that the official distinction in C is between automatic and non-automatic storage.)
- knorker 11mo agoYes. That's escape analysis. But this is not what OP did. What you wrote is not the same in C and Go, because GC and escape analysis. But 9rx is also correct that what OP wrote is the same in C and Go. So OP almost learned about escape analysis, but their example didn't actually do it. So double confusion on their side.
- foldr 11mo agoWell, my point is that escape analysis has nothing to do with it at the semantic level. So it's actually just 'because GC'. You don't need the concept of escape analysis at all to understand the behavior of the Go example.
- knorker 11mo agoYeah. That's what I said.
- foldr 11mo agoI mean that escape analysis has nothing to do with my example either, in terms of understand the semantics of the code (so I’m disagreeing with the ‘because GC and escape analysis’ part of your comment).
- knorker 11mo agoYour https://news.ycombinator.com/item?id=46234206 https://news.ycombinator.com/item?id=46234206 relies on escape analysis though, right? Escape analysis is the reason your `x` is on the heap. Because it escaped. Otherwise it'd be on the stack.[1] Now if by "semantics of the code" you mean "just pretend everything is on the heap, and you won't need to think about escape analysis", then sure. Now in terms of what actually happens, your code triggers escape analysis, and OP does not. [1] Well, another way to say this I guess is that without escape analysis, a language would be forced to never use the stack.