5 ms·

We have integer madness here and no one is commenting on it. Why making this int change and why now? I don't like Java, but well-defined integer types sizes is

by przemoc 14y ago

We have integer madness here and no one is commenting on it. Why making this int change and why now? I don't like Java, but well-defined integer types sizes is a good thing. Most of the world uses intXX_t typedefs in C and C++ too.

dchest 14y ago
It doesn't matter much in Go: integer types with defined sizes are intXX/uintXX, which are not convertible to int/uint implicitly. http://golang.org/ref/spec#Numeric_types http://golang.org/ref/spec#Numeric_types
mseepgood 14y ago
Go has (u)int8, (u)int16, (u)int32, (u)int64 types if you must make assumptions about the size.
laumars 14y ago
Nobody is commenting because there isn't any integer madness. If the size of an integer is critical to the execution of your program, then you should be using int16 or one of the many other types that specify the number of (un)signed bits. The int type is designed to be platform specific to optimize on execution speed when the maximum size of the integer isn't an issue. http://golang.org/ref/spec#Numeric_types http://golang.org/ref/spec#Numeric_types
- przemoc 14y ago
  See my response to grey-area. And regarding optimization. Language-defined integer type size is one thing and CPU register sizes used in calculations is different thing. It's not like having 32-bit int forces you (or compiler) to use 32-bit registers. For every int we (i.e. programmers) should be aware of possible min and max values that can be stored in it. Thus we can easily use fixed-size ints everywhere, paying attention to signedness too of course. The problem is that there is high temptation of using int most of the time, because it's easier to write (it's shorter). For the same reason many C programs use int instead of unsigned short or uint16_t for instance. Well-defined int size is part of self-documenting code, as it shows mindfully applied constraints.
  - laumars 14y ago
    There's arguments for and against both methods. Back when I first started programming, memory was a luxury (we're talking 80's personal computers here), so it made a great deal of difference. These days, however, choosing an integer type which most closely matches the values stored is largely an academic process which costs developer time (though obviously there are exceptions, times when it makes more sense to be mindful and times when it makes less sense). My point is this: the problem when talking about "best practices" is there's some approaches that actually doesn't make a huge deal of practical difference, so it's more subject to specific circumstances (eg developer time constraints) or even just personal preferences (eg the arguments between ()\n{\n\t and (){\ Anyhow, in answer to your other post, the intn and uintn types have been available in Go since day one. So (and in answer to your original post as well), this int issue you raise isn't an issue unless developers have written extremely bad code to begin with (ie written counters which they know will exceed a 32bit integer and not cared enough to write an error handler nor specifically use an int64 type). Go does do a lot more to protect the developer from shooting his own foot off (more so than C/C++), but if we're completely honest, if the developer is crap then no amount of hand-holding from language design will help.
    - gngeal 14y ago
      "There's arguments for and against both methods. Back when I first started programming, memory was a luxury (we're talking 80's personal computers here), so it made a great deal of difference. These days, however, choosing an integer type which most closely matches the values stored is largely an academic process which costs developer time" Actually, memory is even more of a luxury than ever, since your caches have limited size and main memory bandwidth is atrocious, compared to the speed of your execution units. Using 32 bit fields for stuff that safely fits into 16 bits can cost you for that reason alone.
      - laumars 14y ago
        Sorry, but that's not the same as a program crashing to run because you've exceeded 64KB of RAM. Plus your program will spend a great deal of time off the cache anyway (thanks to the OS overhead and any multitasking taking place). I'm all for performance tuning and writing efficient code (like I said, I learn to program back in the 80s when every bit of data mattered and various tricks were used to work around the limited power of those systems), but let's be clear about one thing, memory these days is not "more of a luxury than ever". The exact opposite is true.
- deleted 14y ago
  [deleted]
grey-area 14y ago
Go uses specific int types like uint32, int32 and int64 etc. so it does have well-defined integer types. It does also have a platform specific int type - like C or C++ the size of int can vary depending on the platform, so it's probably best avoided for any operation which cares about the size/precision. In practice, as noted in the link, this is not a big deal as most people will use a specific type to avoid any potential issues, particularly when dealing with bitfields etc. you should be doing this anyway.
- przemoc 14y ago
  Ok, apparently my message wasn't clear. (It was written on the mobile phone, so it was too brief.) In practice, only when you're writing some loops with small number of iterations etc., you don't care whether your counter for instance is 24-bit integer or 48-bit, because 16-bit or maybe even 8-bit would be enough. In most other cases you care whether 64-bit value will fit into your value or not and whether it can be there at all. And if you care about memory you use smaller ints in your structures when bigger ones aren't needed. So, to some extent, it is indeed not a big deal. But it still isn't "not an issue". We gain more than 2^31-1 elements in slices on 64-bit platforms, true, but it should be possible from the beginning, without need to redefine int on such platforms. > Previous Go implementations made int and uint 32 bits on all systems. > Among other things, this enables the allocation of slices with more than 2 billion elements on 64-bit platforms. If they truly wanted to have platform-dependent int, then why 64-bit int on 64-bit platforms wasn't introduced from day 0? It's a valid question, because it would avoid this big (implementation) change at all. > However, programs that contain implicit assumptions that int is only 32 bits may change behavior. I can agree that this assumption is wrong, but why changing int implementation now? > Due to the change of the int to 64 bits and some other changes, the arrangement of function arguments on the stack has changed in the gc tool chain. Functions written in assembly will need to be revised at least to adjust frame pointer offsets. My main point is that variable-sized int implementation and usage gives more problems than we get profits in return, even more when previous and widely used 1.0 version, which 1.1 is going to be backward-compatible with, did it differently. Again, I wouldn't comment if variable-sized int was in Go 1.0 implementation, but it wasn't.
vanderZwan 14y ago
Yeah, but C and C++ have implicit casting where Go doesn't, so this is not quite the same issue. And quite frankly, if your code relies on a an integer to be 32 or 64 bits, you should be using int32 or int64.
zemo 14y ago
because it was consistently communicated that int is currently 32 bits wide but that it would be changing to be architecture-specific; this has been a planned change for a very long time. It has always been the case that if you needed width-specific behaviors, you specify int32 instead of int.

by przemoc 14y ago

dchest 14y ago

It doesn't matter much in Go: integer types with defined sizes are intXX/uintXX, which are not convertible to int/uint implicitly. http://golang.org/ref/spec#Numeric_types http://golang.org/ref/spec#Numeric_types

mseepgood 14y ago

Go has (u)int8, (u)int16, (u)int32, (u)int64 types if you must make assumptions about the size.

laumars 14y ago

Nobody is commenting because there isn't any integer madness. If the size of an integer is critical to the execution of your program, then you should be using int16 or one of the many other types that specify the number of (un)signed bits. The int type is designed to be platform specific to optimize on execution speed when the maximum size of the integer isn't an issue. http://golang.org/ref/spec#Numeric_types http://golang.org/ref/spec#Numeric_types

przemoc 14y ago
See my response to grey-area. And regarding optimization. Language-defined integer type size is one thing and CPU register sizes used in calculations is different thing. It's not like having 32-bit int forces you (or compiler) to use 32-bit registers. For every int we (i.e. programmers) should be aware of possible min and max values that can be stored in it. Thus we can easily use fixed-size ints everywhere, paying attention to signedness too of course. The problem is that there is high temptation of using int most of the time, because it's easier to write (it's shorter). For the same reason many C programs use int instead of unsigned short or uint16_t for instance. Well-defined int size is part of self-documenting code, as it shows mindfully applied constraints.
- laumars 14y ago
  There's arguments for and against both methods. Back when I first started programming, memory was a luxury (we're talking 80's personal computers here), so it made a great deal of difference. These days, however, choosing an integer type which most closely matches the values stored is largely an academic process which costs developer time (though obviously there are exceptions, times when it makes more sense to be mindful and times when it makes less sense). My point is this: the problem when talking about "best practices" is there's some approaches that actually doesn't make a huge deal of practical difference, so it's more subject to specific circumstances (eg developer time constraints) or even just personal preferences (eg the arguments between ()\n{\n\t and (){\ Anyhow, in answer to your other post, the intn and uintn types have been available in Go since day one. So (and in answer to your original post as well), this int issue you raise isn't an issue unless developers have written extremely bad code to begin with (ie written counters which they know will exceed a 32bit integer and not cared enough to write an error handler nor specifically use an int64 type). Go does do a lot more to protect the developer from shooting his own foot off (more so than C/C++), but if we're completely honest, if the developer is crap then no amount of hand-holding from language design will help.
  - gngeal 14y ago
    "There's arguments for and against both methods. Back when I first started programming, memory was a luxury (we're talking 80's personal computers here), so it made a great deal of difference. These days, however, choosing an integer type which most closely matches the values stored is largely an academic process which costs developer time" Actually, memory is even more of a luxury than ever, since your caches have limited size and main memory bandwidth is atrocious, compared to the speed of your execution units. Using 32 bit fields for stuff that safely fits into 16 bits can cost you for that reason alone.
    - laumars 14y ago
      Sorry, but that's not the same as a program crashing to run because you've exceeded 64KB of RAM. Plus your program will spend a great deal of time off the cache anyway (thanks to the OS overhead and any multitasking taking place). I'm all for performance tuning and writing efficient code (like I said, I learn to program back in the 80s when every bit of data mattered and various tricks were used to work around the limited power of those systems), but let's be clear about one thing, memory these days is not "more of a luxury than ever". The exact opposite is true.
deleted 14y ago
[deleted]

grey-area 14y ago

Go uses specific int types like uint32, int32 and int64 etc. so it does have well-defined integer types. It does also have a platform specific int type - like C or C++ the size of int can vary depending on the platform, so it's probably best avoided for any operation which cares about the size/precision. In practice, as noted in the link, this is not a big deal as most people will use a specific type to avoid any potential issues, particularly when dealing with bitfields etc. you should be doing this anyway.

przemoc 14y ago
Ok, apparently my message wasn't clear. (It was written on the mobile phone, so it was too brief.) In practice, only when you're writing some loops with small number of iterations etc., you don't care whether your counter for instance is 24-bit integer or 48-bit, because 16-bit or maybe even 8-bit would be enough. In most other cases you care whether 64-bit value will fit into your value or not and whether it can be there at all. And if you care about memory you use smaller ints in your structures when bigger ones aren't needed. So, to some extent, it is indeed not a big deal. But it still isn't "not an issue". We gain more than 2^31-1 elements in slices on 64-bit platforms, true, but it should be possible from the beginning, without need to redefine int on such platforms. > Previous Go implementations made int and uint 32 bits on all systems. > Among other things, this enables the allocation of slices with more than 2 billion elements on 64-bit platforms. If they truly wanted to have platform-dependent int, then why 64-bit int on 64-bit platforms wasn't introduced from day 0? It's a valid question, because it would avoid this big (implementation) change at all. > However, programs that contain implicit assumptions that int is only 32 bits may change behavior. I can agree that this assumption is wrong, but why changing int implementation now? > Due to the change of the int to 64 bits and some other changes, the arrangement of function arguments on the stack has changed in the gc tool chain. Functions written in assembly will need to be revised at least to adjust frame pointer offsets. My main point is that variable-sized int implementation and usage gives more problems than we get profits in return, even more when previous and widely used 1.0 version, which 1.1 is going to be backward-compatible with, did it differently. Again, I wouldn't comment if variable-sized int was in Go 1.0 implementation, but it wasn't.

vanderZwan 14y ago

Yeah, but C and C++ have implicit casting where Go doesn't, so this is not quite the same issue. And quite frankly, if your code relies on a an integer to be 32 or 64 bits, you should be using int32 or int64.

zemo 14y ago

because it was consistently communicated that int is currently 32 bits wide but that it would be changing to be architecture-specific; this has been a planned change for a very long time. It has always been the case that if you needed width-specific behaviors, you specify int32 instead of int.