On 01/22/2012 01:31 AM, Marco Leise wrote:
Am 22.01.2012, 08:23 Uhr, schrieb bcs <b...@example.com>:
On 01/21/2012 10:05 PM, Walter Bright wrote:
http://news.ycombinator.com/item?id=3495283
and getting rid of unsigned types is not the solution to signed/unsigned
issues.
A quote from that link:
"There are many use cases for data types that behave like pure bit
strings with no concept of sign."
Why not recast the concept of unsigned integers as "bit vectors (that
happen to implement arithmetic)"? I've seen several sources claim that
uint (and friends) should never be used unless you are using it for
low level bit tricks and the like.
Those are heretics.
Rename them bits{8,16,32,64} and make the current names aliases.
So everyone uses int, and we get messages like: "This program currently
uses -1404024 bytes of RAM". I have strong feelings against using signed
types for variables that are ever going to only hold positive numbers,
especially when it comes to sizes and lengths.
OK, I'll grant that there are a (*extremely* limited) number of cases
where you actually need the full range of an unsigned integers type. I'm
not suggesting that the actual semantics of the type be modified and it
would still be usable for exactly that sort of cases. My suggestion is
that the naming be modified to avoid suggesting that the *primary* use
for the type is for non negative numbers.
To support that position, if you really expect to encounter and thus
need to correctly handle numbers between 2^31 and 2^32 (or 63/64, etc.)
then you already need to be doing careful analyses to avoid bugs from
overflow. At that point, you are already considering low level details
and using a "bit vector" type as a number is not much more complicated.
The added bonus is that the mismatch between the name and what it's used
for is a big red flag saying "be careful or this is likely to cause bugs".
Getting people to think of it that way is likely to prevent more bugs
that it cause.
