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

101–110 of 357 posts

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

#101

Post by oefrha »

nialv7 wrote: post #57
harry8 wrote: post #25

Is C++ capable of deprecating or simplifying anything? Honest question, haven't followed closely. rand() is broken,I;m told unfixable and last I heard still wasn't deprecated. Is this proposal a test? "Can we even drop support for a solution to a problem literally nobody has?"

well they managed to get two's complement requirement into C++20. there is always hope.

Well then someone somewhere with some mainframe got so angry they decided to write a manifesto to condemn kids these days and announced a fork of Qt because Qt committed the cardinal sin of adopting C++20. So don’t say “a problem literally nobody has”, someone always has a use case; although at some point it’s okay to make a decision to ignore them.

https://lscs-software.com/LsCs-Manifesto.html

https://news.ycombinator.com/item?id=41614949

Edit: Fixed typo pointed out by child.

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

#102

Post by AlienRobot »

Animats wrote: post #37
AlienRobot wrote: post #22

I wish I knew what a 9 bit byte means. One fun fact I found the other day: ASCII is 7 bits, but when it was used with punch cards there was an 8th bit to make sure you didn't punch the wrong number of holes. https://rabbit.eng.miami.edu/info/ascii.html

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 true for 36-bit CPUs or does it mean something else? If it's something else, then that means 64-bit isn't the "word" of a 64-bit CPU, so what would the word be?

This is all very confusing.

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

#103

Post by mrpippy »

harry8 wrote: post #25

Is C++ capable of deprecating or simplifying anything? Honest question, haven't followed closely. rand() is broken,I;m told unfixable and last I heard still wasn't deprecated. Is this proposal a test? "Can we even drop support for a solution to a problem literally nobody has?"

C++17 removed trigraphs

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

#104

Post by davemp »

inkyoto wrote: post #92
donatj wrote: post #61

Earlier quoted context omitted.

Can you explain how that's helpful? I'm not being obtuse, I just don't follow

Because modern computing has settled on the Boolean (binary) logic (0/1 or true/false) in the chip design, which has given us 8 bit bytes (a power of two). It is the easiest and most reliable to design and implement in the hardware. On the other hand, if computing settled on a three-valued logic (e.g. 0/1/«something» where «something» has been proposed as -1, «undefined»/«unknown»/«undecided» or a «shade of grey»), w…

> On the other hand, if computing settled on a three-valued logic (e.g. 0/1/«something» where «something» has been proposed as -1, «undefined»/«unknown/undecided» or a «shade of grey»), we would have had 9 bit bytes (a power of three).

Is this true? 4 ternary bits give you really convenient base 12 which has a lot of desirable properties for things like multiplication and fixed point. Though I have no idea what ternary building blocks would look like so it’s hard to visualize potential hardware.

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

#105

Post by cogman10 »

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.

Yeah, this is something Java got right as well. It got "unsigned" wrong, but it got standardizing primitive bits correct

byte = 8 bits

short = 16

int = 32

long = 64

float = 32 bit IEEE

double = 64 bit IEEE

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

#106

Post by cogman10 »

pabs3 wrote: post #98

Hmm, I wonder if any modern languages can work on computers that use trits instead of bits. https://en.wikipedia.org/wiki/Ternary_computer

It'd just be a translation/compiler problem. Most languages don't really have a "bit", instead it's usually a byte with the upper bits ignored.

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

#107

Post by ripe »

oefrha wrote: post #101
nialv7 wrote: post #57

Earlier quoted context omitted.

well they managed to get two's complement requirement into C++20. there is always hope.

Well then someone somewhere with some mainframe got so angry they decided to write a manifesto to condemn kids these days and announced a fork of Qt because Qt committed the cardinal sin of adopting C++20. So don’t say “a problem literally nobody has”, someone always has a use case; although at some point it’s okay to make a decision to ignore them. https://lscs-software.com/LsCs-Manifesto.html https://news.ycombinat…

> because Qt committed the carnal sin of adopting C++20

I do believe you meant to write "cardinal sin," good sir. Unless Qt has not only become sentient but also corporeal when I wasn't looking and gotten close and personal with the C++ standard...

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

#108

Post by jltsiren »

cogman10 wrote: post #105
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.

Yeah, this is something Java got right as well. It got "unsigned" wrong, but it got standardizing primitive bits correct byte = 8 bits short = 16 int = 32 long = 64 float = 32 bit IEEE double = 64 bit IEEE

I like the Rust approach more: usize/isize are the native integer types, and with every other numeric type, you have to mention the size explicitly.

On the C++ side, I sometimes use an alias that contains the word "short" for 32-bit integers. When I use them, I'm explicitly assuming that the numbers are small enough to fit in a smaller than usual integer type, and that it's critical enough to performance that the assumption is worth making.

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

#109

Post by cogman10 »

spongebobstoes wrote: post #66
donatj wrote: post #61

Earlier quoted context omitted.

Can you explain how that's helpful? I'm not being obtuse, I just don't follow

One thought is that it's always a whole number of bits (3) to bit-address within a byte. It's 3.5 bits to bit address a 10 bit byte. Sorta just works out nicer in general to have powers of 2 when working on base 2.

This is basically the reason.

Another part of it is the fact that it's a lot easier to represent stuff with hex if the bytes line up.

I can represent "255" with "0xFF" which fits nice and neat in 1 byte. However, now if a byte is 10bits that hex no longer really works. You have 1024 values to represent. The max value would be 0x3FF which just looks funky.

Coming up with an alphanumeric system to represent 2^10 cleanly just ends up weird and unintuitive.

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

#110

Post by poincaredisk »

gerdesj wrote: post #100
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.

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

A bit is either a 0 or 1. A byte is the smallest addressable piece of memory in your architecture.
Post reply on HN