Re: Built-in Type Safety?
Posted: Jan 16, 2006 4:05 AM
> I actually like unsigned types. Without them, you waste a
> lot of memory for unbounded integers that can grow beyond
> the normal 32 or 64 bits (or rather beyond the size
> allowed by the compiler). You need unsigned ints to
> represent larger signed ints.
If you really need that most significant bit of an unsigned number, you're dangerously close to wrapping.
> This results in infinite
> amounts of frustration with Java where you waste twice as
> much memory for nothing.
On the other hand, a guarantee over size and a guaranteed 8 byte long can be of use. For example, you don't really need to worry about timer wrap in Java code. Not in the lifetime of this planet, anyway.
A 4 byte unsigned milliseconds timer wraps quite often.
> They're also necessary if you
> want to right shift without setting the high bit if you're
> manipulating bits and not numbers per se.
I hope its clear that bit shifting should always be done on unsigned values.
Scott Meyers wrote an interesting article promoting the use of signed ints in interfaces.
"Signed and Unsigned Types in Interfaces"
> Overall, I found all the examples to be lack of experience
> or knowledge.
Nonetheless, I hope some readers may benefit. FWIW, these are true stories, and experienced programmers really were caught out.
> Yes, they happen to the best of us and
> there should be better ways. I don't think there's any
> argument there. But if you use a non-saturated integer
> type, you have to expect some problems if you don't check
> your math.
> When I saw the width, height example, I was thinking
> that's got to be reversal of x and y. Happens all the
> time to anyone that's done any kind of graphics.
Yes, I agree. My point is that what appeared to be a type-related problem did not get caught by the compiler. Only careful system testing caught the error. There are techniques enabling you to lean harder on the type system and catch this problem.
> I didn't see anything in this article that isn't part of
> any normal programmer's learning curve. BTW, the type
> safety you mention is a little odd. In C++/C, the type
> mechanism is only there to help you use the same type.
> What you do with those types is up to you. An int or
> r unsigned int is not a saturated type or bounded in any
> way. That's your choice to use them and so you have to
> accept the errors you encounter if you don't use something
> Nice examples and good for any learning programmer.
> if you don't watch what the properties of the types you
> use are, then there's nothing any language or technique is
> gonna be able to do to help you.
Testing can still help.