4 ms·

My question about Go: why does it need pointers? Given that it has garbage collection, arrays/slices, and it disallows pointer arithmetic, it seems it would su

by matthw 17y ago

My question about Go: why does it need pointers? Given that it has garbage collection, arrays/slices, and it disallows pointer arithmetic, it seems it would suffice to use references everywhere. I thought maybe it was for easy interop with C APIs, but it seems it needs a FFI for that anyway. Perhaps someone can enlighten me about that design decision? I'm sure there's a reason, I just don't immediately see it.

dkersten 17y ago
I assume its because they don't want references everywhere. For example, allowing the programmer to choose if an object is allocated on the stack or heap, passed by reference (using a pointer) or by value.
- matthw 17y ago
  Ah, of course. Although, gotta wonder how these stack-allocated objects interact with closures.
  - dkersten 17y ago
    Other languages that support closures have stack allocated objects too. So its no different in this case. Maybe this wikipedia article has details: http://en.wikipedia.org/wiki/Thunk http://en.wikipedia.org/wiki/Thunk
    - barrkel 17y ago
      C-style stack allocated objects captured by closures are not memory-safe in the absence of escape analysis. If the closure outlives the stack frame that allocated the object, a dangling pointer may occur, unless the stack frame itself is allocated on the heap, or the captured objects are moved by the compiler into a structure which is itself allocated on the heap.
      - dkersten 17y ago
        Exactly, the stack frame needs to survive with the Closure.
- euroclydon 17y ago
  Can you elaborate on when an object is "allocated on the stack" versus being "allocated on the heap" in Go?
  - dkersten 17y ago
    I cant, since I'm not terribly familiar with Go. Like I said, I assume that this is the reasoning behind supporting pointers, rather than references to everything. I did not actually check.
  - dkersten 17y ago
    The echo program from the tutorial[1], line 21: var s string = ""; Now, I don't see it written there that it is on the stack, but I imagine so. From the source code of 6g, in cgen.c[2], line 884, you can see this comment: /* * n is on stack, either local variable * or return value from function call. * return n's offset from SP. */ Sounds to me that local variables and return values are always on the stack, which makes sense to me. [1] http://golang.org/doc/go_tutorial.html#tmp_44 http://golang.org/doc/go_tutorial.html#tmp_44 [2] http://code.google.com/p/go/source/browse/src/cmd/6g/cgen.c?r=release http://code.google.com/p/go/source/browse/src/cmd/6g/cgen.c?...

by matthw 17y ago

dkersten 17y ago

I assume its because they don't want references everywhere. For example, allowing the programmer to choose if an object is allocated on the stack or heap, passed by reference (using a pointer) or by value.

matthw 17y ago
Ah, of course. Although, gotta wonder how these stack-allocated objects interact with closures.
- dkersten 17y ago
  Other languages that support closures have stack allocated objects too. So its no different in this case. Maybe this wikipedia article has details: http://en.wikipedia.org/wiki/Thunk http://en.wikipedia.org/wiki/Thunk
  - barrkel 17y ago
    C-style stack allocated objects captured by closures are not memory-safe in the absence of escape analysis. If the closure outlives the stack frame that allocated the object, a dangling pointer may occur, unless the stack frame itself is allocated on the heap, or the captured objects are moved by the compiler into a structure which is itself allocated on the heap.
    - dkersten 17y ago
      Exactly, the stack frame needs to survive with the Closure.
euroclydon 17y ago
Can you elaborate on when an object is "allocated on the stack" versus being "allocated on the heap" in Go?
- dkersten 17y ago
  I cant, since I'm not terribly familiar with Go. Like I said, I assume that this is the reasoning behind supporting pointers, rather than references to everything. I did not actually check.
- dkersten 17y ago
  The echo program from the tutorial[1], line 21: var s string = ""; Now, I don't see it written there that it is on the stack, but I imagine so. From the source code of 6g, in cgen.c[2], line 884, you can see this comment: /* * n is on stack, either local variable * or return value from function call. * return n's offset from SP. */ Sounds to me that local variables and return values are always on the stack, which makes sense to me. [1] http://golang.org/doc/go_tutorial.html#tmp_44 http://golang.org/doc/go_tutorial.html#tmp_44 [2] http://code.google.com/p/go/source/browse/src/cmd/6g/cgen.c?r=release http://code.google.com/p/go/source/browse/src/cmd/6g/cgen.c?...