4 ms·

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 differ

by 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.

by przemoc 14y ago

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.