strange design of C# and .NET concering the byte type

[Tony Johansson]

Hello!

If I look at the type that can store whole number(except byte) we have the
signed version called short,int and long.
The unsigned version is called ushort,uint and ushort

So why wasn't the signed version of byte called just byte and the unsigned
version called ubyte which would
have been much more logically compared to the other whole number types.

Now the signed version is called sbyte and the unsigned version is called
byte.
Can't understand why the designers has done it in such a unlogically way.

//Tony

 

[Family Tree Mike]

Hello!

If I look at the type that can store whole number(except byte) we have the
signed version called short,int and long.
The unsigned version is called ushort,uint and ushort

you meant ushort, uint, and ulong.

So why wasn't the signed version of byte called just byte and the unsigned
version called ubyte which would
have been much more logically compared to the other whole number types.

Now the signed version is called sbyte and the unsigned version is called
byte.
Can't understand why the designers has done it in such a unlogically way.

//Tony

Just a guess, but short, int, long, and byte are somewhat more commonly used
than ushort, uint, ulong, and sbyte. I believe many legacy languages used
similar namings.

Mike

 

[Tony Johansson]

you meant ushort, uint, and ulong.




Just a guess, but short, int, long, and byte are somewhat more commonly
used
than ushort, uint, ulong, and sbyte. I believe many legacy languages used
similar namings.

Mike

I still find it very strange and unlogically calling the signed byte for
sbyte.
Using the name sbyte doesn't fit well here. The designers perhaps missed
this.

//Tony

 

[Geoffrey Summerhayes]

"Family Tree Mike" <[email protected]> skrev i
meddelandet










I still find it very strange and unlogically calling the signed byte for
sbyte.
Using the name sbyte doesn't fit well here. The designers perhaps missed
this.

No, it's deliberate, bytes are usually used as unsigned numbers, using
them
as signed numbers is the odd case. But some of it comes from C where
a
byte isn't really included in the integer hierarchy. Given the widths
of data
paths and registers in modern processors it's usually better to use
larger
types, unless you are really strapped for space. YMMV.

 

[Harlan Messinger]

I still find it very strange and unlogically calling the signed byte for
sbyte.
Using the name sbyte doesn't fit well here. The designers perhaps missed
this.

Do you seriously believe the designers didn't notice something this obvious?

I do think it was for historical reasons. Numbers always needed to
encompass both positive and negative values (as well as zero), and did
so from the beginning. Repackaging them into unsigned types to double
their extent on the positive side was an extension to their original
use. Bytes, on the other hand, aren't implicitly numbers, but building
blocks used to construct numbers as well as characters and CPU
instruction codes and whatever else. Even when they are used as numbers,
they usually represent inherently positive (or zero) values, such as
ASCII character codes and memory locations. In their case, it was
treating them as *signed* values that is the extension.

 

[Peter Duniho]

I still find it very strange and unlogically calling the signed byte for
sbyte.
Using the name sbyte doesn't fit well here. The designers perhaps missed
this.

As Harlan says, the idea that the C# designers didn't carefully consider
the naming of byte/sbyte vs the other types is ludicrous.

You are confusing the words "logical" and "consistent". I agree that
the design is "inconsistent". However, it's entirely logical. There
are two common ways that byte data is used:

– simply as a buffer for binary data
– as individual components of larger data types

For the former, the signed/unsigned doesn't matter at all. It's just a
bucket for bits and no one cares about sign. For the latter, unsigned
is _much_ more convenient than signed. If the types were signed, then
you'd have to be very careful about sign extension, casting of literals,
etc. With unsigned, all of that stuff is implicit and "just works".

Signed byte data is practically never of any use. It hardly ever comes up.

So, while the design is inconsistent with the other types, it's
absolutely logical to do it that way.

"Foolish consistencies are the hobgoblin of little minds" (or something
like that).

Pete

 

[Arne Vajhøj]

If I look at the type that can store whole number(except byte) we have the
signed version called short,int and long.
The unsigned version is called ushort,uint and ushort

So why wasn't the signed version of byte called just byte and the unsigned
version called ubyte which would
have been much more logically compared to the other whole number types.

Now the signed version is called sbyte and the unsigned version is called
byte.
Can't understand why the designers has done it in such a unlogically way.

Simple.

For 16, 32 and 64 bit integers programmers typical want signed
behavior or can live with signed behavior.

For 8 bit integers programmers typical want unsigned
behavior.

So short, int and long were made signed and byte unsigned. And
then adding u and s prefixes respectively can change that.

In Java byte is signed and many C/C++ implementations have
char as signed as well. And people *HATE* it.

So the C# way is very programmer friendly.

Arne

 

[Peter Duniho]

[...]
In Java byte is signed and many C/C++ implementations have
char as signed as well. And people *HATE* it.

I'm no C/C++ spec-geek, but AFAIK "char" is always signed in C/C++.
That's why you also have "unsigned char", which is usually typedef'ed as
"BYTE" (as in the Windows SDK header files).

So the C# way is very programmer friendly.

Agreed!

Pete

 

[Arne Vajhøj]

[...]
In Java byte is signed and many C/C++ implementations have
char as signed as well. And people *HATE* it.

I'm no C/C++ spec-geek, but AFAIK "char" is always signed in C/C++.
That's why you also have "unsigned char", which is usually typedef'ed as
"BYTE" (as in the Windows SDK header files).

Whether C/C++ char is signed or unsigned is implementation specific.

For MS compilers it is signed unless /J is used which make it unsigned.

The typical Win32 definition should be:

typedef unsigned char BYTE;

Arne