Inconsistent Struct Naming in .NET: sbyte/byte and Why Not Int8/UInt8.

[RSReswin]

sbyte -128 to 127 Signed 8-bit integer System.SByte
byte 0 to 255 Unsigned 8-bit integer System.Byte
short -32,768 to 32,767 Signed 16-bit integer System.Int16
ushort 0 to 65,535 Unsigned 16-bit integer System.UInt16
int -2,147,483,648 to 2,147,483,647 Signed 32-bit integer System.Int32
uint 0 to 4,294,967,295 Unsigned 32-bit integer System.UInt32
long -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 Signed 64-bit integer System.Int64
ulong 0 to 18,446,744,073,709,551,615 Unsigned 64-bit integer System.UInt64

All Integral Data Type Struct have proper naming like Int16, UInt16, Int32, UInt32.

non "U" char - to +
with "U" 0 to +
and Size also in that Struct name Int16, Int32, Int64 everting good.

but why Sbyte and byte naming was different, have any reason for this ?

why not Int8 and UInt8 ?

[TahirAhmadov]

Historically and currently, bytes are much more frequently used as unsigned, therefore they chose to make byte default to unsigned. Whereas with larger sized numbers, it's more frequent to go with signed types, with unsigned being the less frequent option.

WRT "why not Int8 and UInt8", it does look like it's inconsistent with other types, but for naming purposes, they made that choice back in the day - difficult to say now - but I'm willing to bet that they did it to be consistent with the languages, because originally the first versions of both the framework and C# were designed together. Byte was just decided to be a "special" integer type - and that "specialness" was consistently applied across the languages and the framework.

PS. Don't quote me on any of this - I wasn't part of decision making about any of this.

[HaloFour]

This is more a runtime question as C# has it's own names for those types, none of which include the size of the type. As mentioned by @TahirAhmadov I believe the signed-ness aspect of the name was to indicate which was expected to be more commonly used and supported, and this is reflected in the Common Language Specification where the only unsigned type considered compliant is byte.

[Flutterish]

imo byte and char aren't numbers. one represents arbitrary data and the other is a "letter"

[RSReswin]

if feel the struct name is be Int8 and UInt8, when working in max memory optimization projects, it is easy to understand, for byte and sbyte struct naming wand to keep that in mind it is how much bytes taking in that memory.

normal users using keyword with differ naming and max memory optimization mind set users use struct with proper memory size naming in struct.

[jnm2]

I feel that "how many bytes does a byte take up" answers itself. Same with "signed byte."

[orthoxerox]

Microsoft adopted <stdint.h> only in VS 2010. Even gcc added it only in 2001. Back around the turn of the millennium, when C# was being designed, there was no real point of reference for language designers to rationalize the switch to [u]intN or {u|i}N naming schema away from C's unsigned char/short/int/long.

[wherewhere]

Why bool is not Int1 and cannot convert it to other Ints? 😜
(Why bool is Int8...

[RSReswin]

nice but in c# bool is already 1byte so what is the use of it >?

[theunrepentantgeek]

Why bool is not Int1 and cannot convert it to other Ints? 😜
(Why bool is Int8...)

bool is byte sized because it's hugely more performant for most processors (certainly, all the target processors at the time .NET & C# were being designed) to read/write byte values. (Generally, performance is better yet for values aligned to 8- or 16-byte boundaries, but given target machines of the era commonly had a fraction of a GB of memory, that was considered spendthrift.)

Also, keep in mind that C# is (largely) a strongly typed language. A bool is not an int is not a byte is not a word. The incompatibilities between these things are a feature not a bug - the original language designers were well aware of the way loose rules in C and C++ were (are!) a fertile source of bugs and chose to make a language where it was easier to avoid mistakes.

[wherewhere]

I saw BitArray is stored by int[]. So that bool[] will 8x bigger than BitArray?
(By the way, BitArray doesn't supports collection expressions...

[FaustVX]

@wherewhere

I saw BitArray is stored by int[]. So that bool[] will 8x bigger than BitArray?

No, the array will contains 4x more elements (an int is 4 byte long, not 8), but each element is 4x shorter, so the final length of the array will be the same.

[wherewhere]

BitArray is store as bit, bool[] is store as 8bit. So bool[] is 8 bigger than BitArray when index length are same.