Jase
Suppose you wanted to store a billion numbers in the range 0 to 200.
Would you rather use only 1GB (using unsigned char), or 8GB (using 64-bit
signed)?
--
Bartc
It's not just the range that differentiates signed and unsigned types.
Unsigned types are required anywhere a "bag of bits" is needed. That
might be for a bit field, representing a physical device, operands for
boolean operations and many other uses.
--
Ian Collins
Yes.
> Java manages perfectly well without them.
I'm prepared to believe you unless evidence to the contrary turns up,
because it's easier than checking.
> Do many people ever use unsigned types nowadays and if so why?
Yes. For me at least, the most important property of an unsigned integer
type is that it cannot, absolutely *cannot*, overflow.
> In a
> 64-bit world, the extra range is rarely worth the hastle it seems to me.
For me, the range isn't the issue.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
What makes you think that this is a 64-bit world? C runs on even
very small systems.
--
Ben Pfaff
http://benpfaff.org
I have never used an __unsung__ type. Whats it like?
--
Billy Mays
http://www.jpgdump.com <- My attempt at humor.
Heroic.
Yes. (Although "unsinged" types are something of a gray area.)
> Java manages perfectly well without
> them.
No, on two counts. First, Java does in fact have an unsigned
integer type. Second, Java's lack of other unsigned types forces
the programmer into silly make-work, with concomitant opportunity
for errors.
> Do many people ever use unsigned types nowadays and if so why?
Yes. The unsigned type I personally use most frequently is
size_t, but sometimes other situations arise where I want to
represent quantities that are necessarily non-negative. Also,
there are the "bag of bits" situations when I want to view an
integer as a collection of flags or small fields (the "unsinged"
or "raw" types are perfect for this). Finally, there are mixed
situations where an integer represents a quantity but must be
manipulated as a bag of bits.
> In a
> 64-bit world, the extra range is rarely worth the hastle it seems to me.
I disagree with the implied premise, but since the argument
seems to be a pure non sequitur my disagreement scarcely matters.
--
Eric Sosman
eso...@ieee-dot-org.invalid
> On 7/2/2010 4:45 PM, Jase Schick wrote:
>> Hi Does C still need unsigned types? Java manages perfectly well without
>> them. Do many people ever use unsigned types nowadays and if so why? In a
>> 64-bit world, the extra range is rarely worth the hastle it seems to me.
>>
>> Jase
>
>
> I have never used an __unsung__ type. Whats it like?
Not very good. At least, I've never heard anyone praising it.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
Here is the first array declaration in the alphabetically first Java source file that I found in the samples folder supplied by Sun for Java for Smart Cards (java_card_kit-2_2_2/samples/src/com/sun/javacard/samples/odSample/packageA/A.java) as I use it
//BApp1AID is the Applet AID for applet BApp1 in packageB
public static byte[] BApp1AID={(byte)0xA0, (byte)0x00,
(byte)0x00, (byte)0x00,
(byte)0x62, (byte)0x03,
(byte)0x01, (byte)0x0C,
(byte)0x07, (byte)0x02,
(byte)0x01};
The first (byte) cast is necessary else that won't compile; thus in Java as practiced in my professional field, it is customary to put (byte) on every byte constant, just as in this example code; and yes, any data processed comes and goes as bytes, there is no other option. Also, BApp1AID[0], which is the byte oh-x-ah-zero, is SMALLER then any other byte in BApp1AID. Now is that "perfectly well"?
> Do many people ever use unsigned types nowadays
Yes.
> and if so why?
For the same reason childs use unsigned numbers: they are simpler to grasp and manipulate. Mathematicians call them "naturals" for a good reason. The result of standard arithmetic operations on C unsigneds is clearly defined and matches a common mathematical notion (modulo UINT_MAX). For many real-life algorithms (e.g. image/video/data compression, extended precision arithmetic, cryptography, data communication), things are most naturally expressed with unsigneds. On many processors that sell by the hundred millions, hardware support for signeds is minimal. I have an example of a silicon manufacturer for SIM card CPUs that dropped support for signed comparison in the instruction set of a CPU introduced circa 2008, otherwise largely binary-compatible with the previous model that had this "feature". Therefore, using signeds on this architecture is considered criminal (an explicit option is needed to make the C compiler generate the ugly code that correctly compares signed var
iables).
> In a 64-bit world,
Which is that of the main CPUs of modern PCs, though not half of these are used in 64-bit mode. And they represent a tiny fraction of CPUs. Do you think your keyboard, mouse, screen have a 64-bit arithmetic unit ? Likely, not even 16, except perhaps in the address path (and that one is unsigned). Or that nobody programed these CPUs ?
> the extra range is rarely worth the hastle it seems to me.
True in that context for individual variables used as counter or indexes. For the rest, size and unsignedness often matters.
Francois Grieu
Yes. If you write code close to hardware like graphics and network
protocol stuff, the lack of unsigned types quickly becomes _the_ most
annoying thing about Java. It was hubris for the Java language
designers to leave them out. A trivial example is that the 4 bytes in
a RGBA pixel each represent a quantity in [0..255] When you e.g. read
back a frame buffer, you must play stupid, inefficient tricks to do
useful computations with the data.
The types referred to in the subject are not so much unsung as unburnt,
as in not even marginally singed.
-=JL=-