Go Data Structures (2009)
research.swtch.com
Go Data Structures (2009)
1–10 of 27 posts
Re: Go Data Structures (2009)
#2Note that this is from 2009. Although the main details have not changed, the int type is more commonly 64 bits now (since 64 bit architectures are much more common)
Re: Go Data Structures (2009)
#3>As an aside, there is a well-known gotcha in Java and other languages that when you slice a string to save a small piece, the reference to the original keeps the entire original string in memory even though only a small amount is still needed. Go has this gotcha too.
That is no longer the case in Java. String.substring() now makes a copy. I think it doesn't matter much which of the two approaches a language takes as long as everybody knows it. This needs to be in the language spec and can't be an implementation issue.
Re: Go Data Structures (2009)
#4Note that this is from 2009. Although the main details have not changed, the int type is more commonly 64 bits now (since 64 bit architectures are much more common)
Do you know what version that happens in? I tested on my 32 and 64 bit platforms with golang 1.1 and a static definition of an integer results in type int (which is explicitly 32 bit)
package main
import "fmt"
import "reflect"
func main() {
i := 3
z := reflect.ValueOf(i)
fmt.Printf("%s\n", z.Kind())
}
// $./test
// int
// $
Re: Go Data Structures (2009)
#5Note that this is from 2009. Although the main details have not changed, the int type is more commonly 64 bits now (since 64 bit architectures are much more common)
Do you know what version that happens in? I tested on my 32 and 64 bit platforms with golang 1.1 and a static definition of an integer results in type int (which is explicitly 32 bit) package main import "fmt" import "reflect" func main() { i := 3 z := reflect.ValueOf(i) fmt.Printf("%s\n", z.Kind()) } // $./test // int // $ It's my understanding that this intentional and won't change, only explicit declarations of in…
It is implementation-specific (from the spec:)
There is also a set of predeclared numeric types with implementation-specific sizes:
uint either 32 or 64 bits
int same size as uint
uintptr an unsigned integer large enough to store the uninterpreted bits of a pointer value
Re: Go Data Structures (2009)
#6>As an aside, there is a well-known gotcha in Java and other languages that when you slice a string to save a small piece, the reference to the original keeps the entire original string in memory even though only a small amount is still needed. Go has this gotcha too. That is no longer the case in Java. String.substring() now makes a copy. I think it doesn't matter much which of the two approaches a language takes as…
for historical note, this change was made in may 2012 Java 7u6
Re: Go Data Structures (2009)
#7Note that this is from 2009. Although the main details have not changed, the int type is more commonly 64 bits now (since 64 bit architectures are much more common)
Do you know what version that happens in? I tested on my 32 and 64 bit platforms with golang 1.1 and a static definition of an integer results in type int (which is explicitly 32 bit) package main import "fmt" import "reflect" func main() { i := 3 z := reflect.ValueOf(i) fmt.Printf("%s\n", z.Kind()) } // $./test // int // $ It's my understanding that this intentional and won't change, only explicit declarations of in…
i := 3 means declare i to be an "int", which is the default numeric type. The size of that int will vary from platform to platform. See http://golang.org/ref/spec#Numeric_types
Re: Go Data Structures (2009)
#8make(* Point) seems much better than having a separate new keyword. Surprised to hear that was changed after just a few days.
Re: Go Data Structures (2009)
#9>As an aside, there is a well-known gotcha in Java and other languages that when you slice a string to save a small piece, the reference to the original keeps the entire original string in memory even though only a small amount is still needed. Go has this gotcha too. That is no longer the case in Java. String.substring() now makes a copy. I think it doesn't matter much which of the two approaches a language takes as…
for historical note, this change was made in may 2012 Java 7u6
That's kind of a big deal for a point release...
Re: Go Data Structures (2009)
#10I wish there were a way to create custom data structures without casting to and from interface{} all the time. Heck, it would already help if there were a shorthand for interface{}, like "any" or something.