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

171–180 of 357 posts

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

#171

Post by bee_rider »

stephencanon wrote: post #158
FooBarBizBazz wrote: post #127

Earlier quoted context omitted.

Whether double floats can silently have 80 bit accumulators is a controversial thing. Numerical analysis people like it. Computer science types seem not to because it's unpredictable. I lean towards, "we should have it, but it should be explicit", but this is not the most considered opinion. I think there's a legitimate reason why Intel included it in x87, and why DSPs include it.

Numerical analysis people do not like it. Having _explicitly controlled_ wider accumulation available is great. Having compilers deciding to do it for you or not in unpredictable ways is anathema.

It isn’t harmful, right? Just like getting a little accuracy from a fused multiply add. It just isn’t useful if you can’t depend on it.

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

#172

Post by bee_rider »

Isamu wrote: post #166
pjdesno wrote: post #15

During an internship in 1986 I wrote C code for a machine with 10-bit bytes, the BBN C/70. It was a horrible experience, and the existence of the machine in the first place was due to a cosmic accident of the negative kind.

I wrote code on a DECSYSTEM-20, the C compiler was not officially supported. It had a 36-bit word and a 7-bit byte. Yep, when you packed bytes into a word there were bits left over. And I was tasked with reading a tape with binary data in 8-bit format. Hilarity ensued.

Hah. Why did they do that?

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

#174

Post by spc476 »

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.

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

#176

Post by bcoates »

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 take you pretty far, but it's a garden path that goes nowhere--eventually you must admit that you know nothing and the best you can do is a formal argument that conditional on the documentation being correct you have constructed a correct program.

This is a huge intellectual leap, and in my personal experience the further you go without being forced to acknowledge it the harder it will be to make the jump.

That said, there seems to be an increasing popularity of physical electronics projects among the novice set these days... hopefully read the damn spec sheet will become the new read the documentation

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

#177

Post by basementcat »

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 a measure of information theoretical entropy. Specifically, one bit has been defined as the uncertainty of the outcome of a single fair coin flip. A single less than fair coin would have less than one bit of entropy; a coin that always lands heads up has zero bits, n fair coins have n bits of entropy and so on.

https://en.m.wikipedia.org/wiki/Information_theory

https://en.m.wikipedia.org/wiki/Entropy_(information_theory)

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

#178

Post by conradev »

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...

I was curious about float16, and TIL that the 2008 revision of the standard includes it as an interchange format:

https://en.wikipedia.org/wiki/IEEE_754-2008_revision

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

#179

Post by jeberle »

josephg wrote: post #112
cogman10 wrote: post #105

Earlier quoted context omitted.

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

Yep. Pity about getting chars / string encoding wrong though. (Java chars are 16 bits). But it’s not alone in that mistake. All the languages invented in that era made the same mistake. (C#, JavaScript, etc).

Java strings are byte[]'s if their contents contain only Latin-1 values (the first 256 codepoints of Unicode). This shipped in Java 9.

JEP 254: Compact Strings

https://openjdk.org/jeps/254

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

#180

Post by eternityforest »

bee_rider wrote: post #171
stephencanon wrote: post #158

Earlier quoted context omitted.

Numerical analysis people do not like it. Having _explicitly controlled_ wider accumulation available is great. Having compilers deciding to do it for you or not in unpredictable ways is anathema.

It isn’t harmful, right? Just like getting a little accuracy from a fused multiply add. It just isn’t useful if you can’t depend on it.

I suppose it could be harmful if you write code that depends on it without realizing it, and then something changes so it stops doing that.
Post reply on HN