I can agree that in some circumstances, a ranged and saturated integer mode would be REALLY handy (colours, sound samples), but I can't buy in with the whole trapping overflows and stuff... most architectures will require explicit checking of the overflow bit after every operation to support this. Also, contrary to his claim, I find that wrapping is usually what I DO want in this case.. It's super rare that I write any code that pushes the limits of an int (unless we're talking 8-16 bit, see my range+saturation comment before), and when I do write code that pushes the range of an int, I can't think of a time when I've not wanted to wrap as expected. If I'm dealing with integers that big, chances are I'm dealing with memory ranges, bit masks, or some compression/crypto type thing where the algorithms depend on it. Not only am I aware of the wrapping behaviour, it's usually the intent...
On 5 December 2011 18:37, Don <[email protected]> wrote: > On 05.12.2011 14:31, bearophile wrote: > >> Found through Reddit, two blog posts about how integers should behave in >> system languages (with hardware support): >> >> http://blog.regehr.org/**archives/641<http://blog.regehr.org/archives/641> >> http://blog.regehr.org/**archives/642<http://blog.regehr.org/archives/642> >> >> Bye, >> bearophile >> > > Not very convincing, since he proposes a change to existing architectures, > and seems completely unaware of the overflow flag. > If you can change existing architectures, why not simply allow an > exception to be generated if an overflow occurs? > > Doesn't seem at all helpful to D. >
