func ParseInt(s string, base int, bitSize int) (i int64, err error)
ParseInt always returns int64.
bitSize defines the range of values.
If the value corresponding to s cannot be represented by a signed integer of the given size, err.Err = ErrRange.
http://golang.org/pkg/strconv/#ParseInt
type int int
int is a signed integer type that is at least 32 bits in size. It is a distinct type, however, and not an alias for, say, int32.
http://golang.org/pkg/builtin/#int
So int could be bigger than 32 bit in the future or on some systems like int in C.
I guess on some systems int64 might be faster than int32 because that system only works with 64-bit integers.
Here is an example of an error when bitSize is 8:
http://play.golang.org/p/_osjMqL6Nj
package main
import (
"fmt"
"strconv"
)
func main() {
i, err := strconv.ParseInt("123456", 10, 8)
fmt.Println(i, err)
}
func ParseInt(s string, base int, bitSize int) (i int64, err error)
ParseInt always returns int64.
bitSize defines the range of values.
If the value corresponding to s cannot be represented by a signed integer of the given size, err.Err = ErrRange.
http://golang.org/pkg/strconv/#ParseInt
type int int
int is a signed integer type that is at least 32 bits in size. It is a distinct type, however, and not an alias for, say, int32.
http://golang.org/pkg/builtin/#int
So int could be bigger than 32 bit in the future or on some systems like int in C.
I guess on some systems int64 might be faster than int32 because that system only works with 64-bit integers.
Here is an example of an error when bitSize is 8:
http://play.golang.org/p/_osjMqL6Nj
package main
import (
"fmt"
"strconv"
)
func main() {
i, err := strconv.ParseInt("123456", 10, 8)
fmt.Println(i, err)
}
Package strconv
func ParseInt
func ParseInt(s string, base int, bitSize int) (i int64, err error)ParseInt interprets a string s in the given base (2 to 36) and returns the corresponding value i. If base == 0, the base is implied by the string's prefix: base 16 for "0x", base 8 for "0", and base 10 otherwise.
The bitSize argument specifies the integer type that the result must fit into. Bit sizes 0, 8, 16, 32, and 64 correspond to int, int8, int16, int32, and int64.
The errors that ParseInt returns have concrete type *NumError and include err.Num = s. If s is empty or contains invalid digits, err.Err = ErrSyntax; if the value corresponding to s cannot be represented by a signed integer of the given size, err.Err = ErrRange.
ParseInt always returns an int64 value. Depending on bitSize, this value will fit into int, int8, int16, int32, or int64. If the value cannot be represented by a signed integer of the size given by bitSize, then err.Err = ErrRange.
The Go Programming Language Specification
Numeric types
The value of an n-bit integer is n bits wide and represented using two's complement arithmetic.
int8 the set of all signed 8-bit integers (-128 to 127) int16 the set of all signed 16-bit integers (-32768 to 32767) int32 the set of all signed 32-bit integers (-2147483648 to 2147483647) int64 the set of all signed 64-bit integers (-9223372036854775808 to 9223372036854775807)There is also a set of predeclared numeric types with implementation-specific sizes:
uint either 32 or 64 bits int same size as uint
int is either 32 or 64 bits, depending on the implementation. Usually it's 32 bits for 32-bit compilers and 64 bits for 64-bit compilers.
To find out the size of an int or uint, use strconv.IntSize.
Package strconv
Constants
const IntSize = intSize
IntSizeis the size in bits of anintoruintvalue.
For example,
package main
import (
"fmt"
"runtime"
"strconv"
)
func main() {
fmt.Println(runtime.Compiler, runtime.GOARCH, runtime.GOOS)
fmt.Println(strconv.IntSize)
}
Output:
gc amd64 linux
64
How to compare int to int64?
Pick the right one: int vs. int64
One of thing is don't try to optimize and be too smart about int size, it will bit you on the end, if you're not sure just use an int64.
More on reddit.comint64 vs int
String to int (not int64) using ParseInt()/Atoi()
int and uint are only 64-bit on 64-bit architectures. On 32-bit architectures they are 32 bits.
The general answer is that, unless you need a certain precision, sticking with datatypes that are the same size as a word on the current architecture (e.g. 32 bits on a 32-bit architecture) is typically slightly more efficient.
int and uint correspond to the maximum possible length of basic Go data structures in a Go implementation and runtime. The length of string, map[K]T, []T and chan T always fits into an int, and the capacity of []T and chan T always fits into an int.
An allocation via make is bound to return an object with length and capacity that always fit into an int. The built-in function append returns a slice with length and capacity that never exceed an int. The length (the number of defined keys) of a map after inserting a new key-value pair always fits into an int.
The main benefit is that int and uint are the smallest (in terms of bitsize) data types which are safe to use in a Go program in conjunction with common Go data types such as slices and maps.
The size of int is independent from the size of a pointer *T. The integer type corresponding to *T is uintptr. In theory, a Go implementation could choose to map int to int16 - many Go programs would remain to work correctly, but limiting the size of allocations to 15 bits may be too restrictive and would cause runtime panics.
On 64-bit architectures Go 1.0 has int and uint 32 bits long, Go 1.1 64 bits long (see Go 1.1 Release Notes). This change will increase the memory usage of some Go programs on 64-bit architectures..
Explicitly using int64 instead of int in a Go program can make it slower under Go 1.0 and on 32-bit architectures because:
of conversions between
intandint64the performance of certain CPU instructions, such as division, depends on the size of operands
Explicitly using int64 instead of int in a Go program can make it faster under Go 1.0 on 64-bit architectures because:
- The compiler can generate more efficient code for address and offset computation if all operands are 64-bit. Mixing 32-bit and 64-bit operands when computing addresses and offsets is slower.
Using uint16 as an index when accessing [1<<16]T allows the compiler to remove bound checking instructions.
I am a Go beginner and trying to understand more about the language by studying code out in the wild. I have been studying this snippet:
https://github.com/hailocab/go-geoindex/blob/master/queue.go
Overall it makes sense.
But I do not understand why in the queue struct the size and cap names are int and not int64, especially as these are cast to int64 throughout the code?
The other part I do not understand is the usage of something%int64(queue.cap)... I understand that means modulo the cap of the queue, presumably to handle the case something tries to access a queue slot that is beyond the queue's capacity but wouldn't it make more sense just to check if something>queue.cap and error out rather than assign a random queue element modulo the queue.cap?
The int64 make no sense. The int does make sense (as that's the type returned by len() and cap() for slices), but mixing int64 and ints doesn't. So they should just stick with int.
To anser the second part: Because it's a circular queue (a popular way to implement a double ended queue). So, you might fill the queue completely (until the underlying slice is filled) and then pop from the front. When you then push, they want to reuse the free space at the start. So they wrap around the index.
Overall, I'd say: Don't fall into the trap of assuming that every go code is good go code. This code in particular doesn't look very good to me, it looks more complicated then it needs to be (for example, they shouldn't really need len or cap) and has quite a bunch of weirdness in it (the int vs. int64 is only the start).
Without looking at the code, on mobile. Compilation makes the 'default' int to either int64 or int 32 depending on arch. I'm still lying in bed and may come back to it later on today if nobody else does. But I hope that bit of info helps.