Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ proposal: There are exactly 8 bits in a byte

open-std.org

Post reply on HN
Print view View original

231–240 of 357 posts

Re: C++ proposal: There are exactly 8 bits in a byte

#231

Post by josefx »

kmeisthax wrote: post #207
Negitivefrags wrote: post #185

Earlier quoted context omitted.

It can be harmful. In GCC while compiling a 32 bit executable, making an std::map can cause infinite loops or crashes in your program. This is because when you insert a value into the map, it has 80 bit precision, and that number of bits is used when comparing the value you are inserting during the traversal of the tree. After the float is stored in the tree, it's clamped to 32 bits. This can cause the element to be…

What use case do you have that requires indexing a hashmap by a floating point value? Keep in mind, even with a compliant implementation that isn't widening your types behind your back, you still have to deal with NaN. In fact, Rust has the Eq trait specifically to keep f32/f64s out of hash tables, because NaN breaks them really bad.

> you still have to deal with NaN.

Detecting and filtering out NaNs is both trivial and reliable as long as nobody instructs the compiler to break basic floating point operations (so no ffast-math). Dealing with a compiler that randomly changes the values of your variables is much harder.

Re: C++ proposal: There are exactly 8 bits in a byte

#232

Post by josefx »

ndesaulniers wrote: post #189
Negitivefrags wrote: post #185

Earlier quoted context omitted.

It can be harmful. In GCC while compiling a 32 bit executable, making an std::map can cause infinite loops or crashes in your program. This is because when you insert a value into the map, it has 80 bit precision, and that number of bits is used when comparing the value you are inserting during the traversal of the tree. After the float is stored in the tree, it's clamped to 32 bits. This can cause the element to be…

Are you mixing up long double with float?

Old Intel CPUs only had long double, 32 bit and 64 bit floats were a compiler hack on top of the 80 bit floating point stack.

Re: C++ proposal: There are exactly 8 bits in a byte

#233

Post by pezezin »

kazinator wrote: post #224
pezezin wrote: post #193

Earlier quoted context omitted.

Then just define a type alias, which is good practice if you want your types to be more descriptive: https://doc.rust-lang.org/reference/items/type-aliases.html

Nope! Because then you will also define an alias, and Suzy will define an alias, and Bob will define an alias, ... We should all agree on int and uint ; not some isize nonsense, and not bobint or suzyint .

Ok, it is obvious that you are looking for something to complaint about and don't want to find a solution. That is not a productive attitude in life, but whatever floats your boat. Have a good day.

Re: C++ proposal: There are exactly 8 bits in a byte

#234

Post by Animats »

AlienRobot wrote: post #102
Animats wrote: post #37

Earlier quoted context omitted.

A 9-bit byte is found on 36-bit machines in quarter-word mode. Parity is for paper tape, not punched cards. Paper tape parity was never standardized. Nor was parity for 8-bit ASCII communications. Which is why there were devices with settings for EVEN, ODD, ZERO, and ONE for the 8th bit. Punched cards have their very own encodings, only of historical interest.

>A 9-bit byte is found on 36-bit machines in quarter-word mode. I've only programmed in high level programming languages in 8-bit-byte machines. I can't understand what you mean by this sentence. So in a 36-bit CPU a word is 36 bits. And a byte isn't a word. But what is a word and how does it differ from a byte? If you asked me what 32-bit/64-bit means in a CPU, I'd say it's how large memory addresses can be. Is that…

A word is the unit of addressing. A 36-bit machine has 36 bits of data stored at address 1, and another 36 bits at address 2, and so forth. This is inconvenient for text processing. You have to do a lot of shifting and masking. There's a bit of hardware help on some machines. UNIVAC hardware allowed accessing one-sixth of a word (6 bits), or one-quarter of a word (8 bits), or one-third of a word (12 bits), or a half of a word (18 bits). You had to select sixth-word mode (old) or quarter-word mode (new) as a machine state.

Such machines are not byte-addressable. They have partial word accesses, instead.

Machines have been built with 4, 8, 12, 16, 24, 32, 36, 48, 56, 60, and 64 bit word lengths.

Many "scientific" computers were built with 36-bit words and a 36-bit arithmetic unit. This started with the IBM 701 (1952), although an FPU came later, and continued through the IBM 7094. The byte-oriented IBM System/360 machines replaced those, and made byte-addressable architecture the standard. UNIVAC followed along with the UNIVAC 1103 (1953), which continued through the 1103A and 1105 vacuum tube machines, the later transistorized machines 1107 and 1108, and well into the 21st century. Unisys will still sell you a 36-bit machine, although it's really an emulator running on Intel Xeon CPUs.

The main argument for 36 bits was that 36-bit floats have four more bits of precision, or one more decimal digit, than 32-bit floats. 1 bit of sign, 8 bits of exponent and 27 bits of mantissa gives you a full 8 decimal digits of precision, while standard 32-bit floats with an 1 bit sign, 7-bit exponent and a 24 bit mantissa only give you 7 full decimal digits. Double precision floating point came years later; it takes 4x as much hardware.

Re: C++ proposal: There are exactly 8 bits in a byte

#235

Post by technion »

bcoates wrote: post #176

I have mixed feelings about this. On the one hand, it's obviously correct--there is no meaningful use for CHAR_BIT to be anything other than 8. On the other hand, it seems like some sort of concession to the idea that you are entitled to some sort of just world where things make sense and can be reasoned out given your own personal, deeply oversimplified model of what's going on inside the computer. This approach can…

And yet every time I run an autoconf script I watch as it checks the bits in a byte and saves the output in config.h as though anyone planned to act on it.

Re: C++ proposal: There are exactly 8 bits in a byte

#236

Post by inkyoto »

donatj wrote: post #60
wvenable wrote: post #59

Earlier quoted context omitted.

I'm not sure why you think being able to store values from -512 to +511 is more logical than -128 to +127?

Buckets of 10 seem more regular to beings with 10 fingers that can be up or down?

Unless they are Addams who have 10 fingers and 11 toes as it is known abundantly well.

Re: C++ proposal: There are exactly 8 bits in a byte

#237

Post by Cloudef »

Laremere wrote: post #144
WalterBright wrote: post #90

D made a great leap forward with the following: 1. bytes are 8 bits 2. shorts are 16 bits 3. ints are 32 bits 4. longs are 64 bits 5. arithmetic is 2's complement 6. IEEE floating point and a big chunk of wasted time trying to abstract these away and getting it wrong anyway was saved. Millions of people cried out in relief! Oh, and Unicode was the character set. Not EBCDIC, RADIX-50, etc.

Zig is even better: 1. u8 and i8 are 8 bits. 2. u16 and i16 are 16 bits. 3. u32 and i32 are 32 bits. 4. u64 and i64 are 64 bits. 5. Arithmetic is an explicit choice. '+' overflowing is illegal behavior (will crash in debug and releasesafe), '+%' is 2's compliment wrapping, and '+|' is saturating arithmetic. Edit: forgot to mention @addWithOverflow(), which provides a tuple of the original type and a u1; there's also…

Zig allows any uX and iX in the range of 1 - 65,535, as well as u0

Re: C++ proposal: There are exactly 8 bits in a byte

#238

Post by seoulbigchris »

thamer wrote: post #130
gerdesj wrote: post #100

Earlier quoted context omitted.

"1. bytes are 8 bits" How big is a bit?

This doesn't feel like a serious question, but in case this is still a mystery to you… the name bit is a portmanteau of binary digit , and as indicated by the word "binary", there are only two possible digits that can be used as values for a bit: 0 and 1.

So trinary and quaternary digits are trits and quits?

Re: C++ proposal: There are exactly 8 bits in a byte

#239

Post by seoulbigchris »

jsheard wrote: post #80
favorited wrote: post #53

Previously, in JF's "Can we acknowledge that every real computer works this way?" series: "Signed Integers are Two’s Complement" https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p09... >

Maybe specifying that floats are always IEEE floats should be next? Though that would obsolete this Linux kernel classic so maybe not. https://github.com/torvalds/linux/blob/master/include/math-e...

Which one? Remember the decimal IEEE 754 floating point formats exist too. Do folks in banking use IEEE decimal formats? I remember we used to have different math libs to link against depending, but this was like 40 years ago.

Re: C++ proposal: There are exactly 8 bits in a byte

#240

Post by kreco »

spc476 wrote: post #174
kreco wrote: post #39

I'm totally fine with enforcing that int8_t == char == 8-bits, however I'm not sure about spreading the misconception that a byte is 8-bits. A byte with 8-bits is called an octet. At the same time, a `byte` is already an "alias" for `char` since C++17 anyway[1]. [1] https://en.cppreference.com/w/cpp/types/byte

My first experience with computers was 45 years ago, and a "byte" back then was defined as an 8-bit quantity. And in the intervening 45 years, I've never come across a different meaning for "byte". I'll ask for a citation for a definition of "byte" that isn't 8-bits.

That's interesting because maybe a byte will not be 8-bit in 45 years from now on.

I'm mostly discussing from the sake of it because I don't really mind as a C/C++ user. We could just use "octet" and call it a day, but now there is an ambiguity with the past definition and potential in the future definition (in which case I hope the term "byte" will just disappear).

Post reply on HN