4 ms·

I checked out the example code for arrays (https://github.com/betty200744/ultimate-go/blob/3de8a053d9f70523af709b4f320f18a5bd0b0c2e/Language_Specification/refer

I checked out the example code for arrays (https://github.com/betty200744/ultimate-go/blob/3de8a053d9f70523af709b4f320f18a5bd0b0c2e/Language_Specification/reference-type/array/arrays.go https://github.com/betty200744/ultimate-go/blob/3de8a053d9f7...) and noticed that OP seems to misunderstand a few things about Go arrays: - the cheat sheet differentiates between 'declaring' and 'declaring and initializing', but in Go there are no uninitialized arrays (or slices) - a lot of times in this file, a slice is created instead of an array (lines 18, 21, 25, 31) - arrays in Go don't really have a capacity (it's always the same as the array's length) - the built-ins append and copy as well as the sort functions don't accept arrays (I assume this is why slices are created?)

axaxs 6y ago
> in Go there are no uninitialized arrays (or slices) This is a little murky and misleading. In Go, you can actually save memory by 'declaring' only. For example, if you do var x []string, and never use x, it never actually uses memory. Whereas x := []string{} does. The JSON encoder treats the two differently, as well.
- yencabulator 6y ago
  Much like the github link, you're confusing slices with arrays. Slices can be nil (data=nil, len=cap=0) or non-nil (data points somewhere, len and cap are what they are), but arrays are just arrays, there's no such thing as an uninitialized [3]byte.
  - axaxs 6y ago
    I'm not. I've been a Go programmer for years, and I literally quoted your comment above mine - it says (or slices)
    - amscanne 6y ago
      I believe your comment is wrong though. Those two things will use exactly the same amount of memory. The data pointer in the slice points to an array-type of size zero. All allocations for objects of size zero return a fixed address in the data section (so there is a distinction between a nil and non-nil object, but a pointer to a zero sized object does not actually take any space). See line 909: https://golang.org/src/runtime/malloc.go https://golang.org/src/runtime/malloc.go
      - axaxs 6y ago
        Flip the first line between true and false, you'll see different memory usage based on declaration type. I haven't analyzed the compiler code, but my assumption is it's forced to return an actual slice object when one is declared with :=. But I'd be happy to be better educated here - https://play.golang.org/p/wVyv0qhj9rp https://play.golang.org/p/wVyv0qhj9rp
        yencabulator 6y ago
        []int{} is a non-nil slice, which allocates. The zero-length optimization probably doesn't exist for arrays in this context, because no sane code does this. This still has nothing to do with "declaring" vs "initializing" (Go makes no such distinction; all values are always "initialized"), or direct use of arrays.
        amscanne 6y ago
        > The zero-length optimization probably doesn't exist for arrays in this context This is no distinction for arrays for non-array. E.g. [0]int is a valid type, and it's size is zero. It is treated exactly the same as all other zero-sized types. This is not a special optimization: there are may cases of zero-sized types. The slice itself is a value type. So foo := []int{} would occupy 24-bytes (data pointer, len, cap) and not necessarily escape to the heap, exactly the same as var foo []string.
        deleted 6y ago
        [deleted]

axaxs 6y ago

> in Go there are no uninitialized arrays (or slices) This is a little murky and misleading. In Go, you can actually save memory by 'declaring' only. For example, if you do var x []string, and never use x, it never actually uses memory. Whereas x := []string{} does. The JSON encoder treats the two differently, as well.

yencabulator 6y ago
Much like the github link, you're confusing slices with arrays. Slices can be nil (data=nil, len=cap=0) or non-nil (data points somewhere, len and cap are what they are), but arrays are just arrays, there's no such thing as an uninitialized [3]byte.
- axaxs 6y ago
  I'm not. I've been a Go programmer for years, and I literally quoted your comment above mine - it says (or slices)
  - amscanne 6y ago
    I believe your comment is wrong though. Those two things will use exactly the same amount of memory. The data pointer in the slice points to an array-type of size zero. All allocations for objects of size zero return a fixed address in the data section (so there is a distinction between a nil and non-nil object, but a pointer to a zero sized object does not actually take any space). See line 909: https://golang.org/src/runtime/malloc.go https://golang.org/src/runtime/malloc.go
    - axaxs 6y ago
      Flip the first line between true and false, you'll see different memory usage based on declaration type. I haven't analyzed the compiler code, but my assumption is it's forced to return an actual slice object when one is declared with :=. But I'd be happy to be better educated here - https://play.golang.org/p/wVyv0qhj9rp https://play.golang.org/p/wVyv0qhj9rp
      - yencabulator 6y ago
        []int{} is a non-nil slice, which allocates. The zero-length optimization probably doesn't exist for arrays in this context, because no sane code does this. This still has nothing to do with "declaring" vs "initializing" (Go makes no such distinction; all values are always "initialized"), or direct use of arrays.
        amscanne 6y ago
        > The zero-length optimization probably doesn't exist for arrays in this context This is no distinction for arrays for non-array. E.g. [0]int is a valid type, and it's size is zero. It is treated exactly the same as all other zero-sized types. This is not a special optimization: there are may cases of zero-sized types. The slice itself is a value type. So foo := []int{} would occupy 24-bytes (data pointer, len, cap) and not necessarily escape to the heap, exactly the same as var foo []string.
      - deleted 6y ago
        [deleted]