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

201–210 of 357 posts

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

#201

Post by bcoates »

joelignaatius wrote: post #184
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…

As with any highly used language you end up running into what I call the COBOL problem. It will work for the vast majority of cases except where there's a system that forces an update and all of a sudden a traffic control system doesn't work or a plane falls out of the sky. You'd have to have some way of testing all previous code in the compilation (pardon my ignorance if this is somehow obvious) to make sure this ma…

That's not really the problem here--CHAR_BIT is already 8 everywhere in practice, and all real existing code[1] handles CHAR_BIT being 8.

The question is "does any code need to care about CHAR_BIT > 8 platforms" and the answer of course is no, its just should we perform the occult standards ceremony to acknowledge this, or continue to ritually pretend to standards compliant 16 bit DSPs are a thing.

[1] I'm sure artifacts of 7, 9, 16, 32, etc[2] bit code & platforms exist, but they aren't targeting or implementing anything resembling modern ISO C++ and can continue to exist without anyone's permission.

[2] if we're going for unconventional bitness my money's on 53, which at least has practical uses in 2024

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

#202

Post by speedgoose »

jcranmer wrote: post #196
jsheard wrote: post #80

Earlier quoted context omitted.

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'm literally giving a talk next week who's first slide is essentially "Why IEEE 754 is not a sufficient description of floating-point semantics" and I'm sitting here trying to figure out what needs to be thrown out of the talk to make it fit the time slot. One of the most surprising things about floating-point is that very little is actually IEEE 754; most things are merely IEEE 754-ish, and there's a long tail of f…

I'm interested by your future talk, do you plan to publish a video or a transcript?

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

#203

Post by [deleted] »

epcoa wrote: post #87
tbrownaw wrote: post #79

Earlier quoted context omitted.

Should be either 9 or 27 I'd think.

Why can’t it be 8?, the fact that it’s a trit doesn’t put any constraint on the byte (tryte ? size). You could actually make it 5 or 6 trits (~9.5 bits) for similar information density. The Setun used 6 trit addressable units.

[deleted]

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

#204

Post by __turbobrew__ »

smaudet wrote: post #195
__turbobrew__ wrote: post #163

Earlier quoted context omitted.

This person is unhinged. > It's a desktop on a Linux distro meant to create devices to better/save lives. If you are creating life critical medical devices you should not be using linux.

> If you are creating life critical medical devices you should not be using linux. Hmm, what do you mean? Like, no you should not adopt some buggy or untested distro, instead choose each component carefully and disable all un-needed updates... But that beats working on an unstable, randomly and capriciously deprecated and broken OS (windows/mac over the years), that you can perform zero practical review, casual or ot…

I mean you should be building life critical medical devices on top of an operating system like QNX or vxworks which are much more stable and simpler.

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

#205

Post by smaudet »

epcoa wrote: post #142
oefrha wrote: post #101

Earlier quoted context omitted.

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…

Wow. https://theminimumyouneedtoknow.com/ https://lscs-software.com/LsCs-Roadmap.html "Many of us got our first exposure to Qt on OS/2 in or around 1987." Uh huh. > someone always has a use case; No he doesn't. He's just unhinged. The machines this dude bitches about don't even have a modern C++ compiler nor do they support any kind of display system relevant to Qt. They're never going to be a target for Qt. Further…

Yeah, I think many of their arguments are not quite up to snuff. I would be quite interested how 1s compliment is faster, it is simpler and thus the hardware could be faster, iff you figure out how to deal with the drawbacks like -0 vs +0 (you could do it in hardware pretty easily...)

Buuuut then the Unisys thing. Like you say they dont make processors (for the market) and themselves just use Intel now...and even if they make some special secret processors I don't think the IRS is using top secret processors to crunch our taxes, even in the hundreds of millions of record realm with average hundreds of items per record, modern CPUs run at billions of ops per second...so I suspect we are talking some tens of seconds, and some modest amount of RAM (for a server).

The one point he does have is interoperability, which if a lot of (especially medical) equipment uses 1s compliment because its cheaper (in terms of silicon), using "modern" tools is likely to be a bad fit.

Compatability is King, and where medical devices are concerned I would be inclined to agree that not changing things is better than "upgrading" - its all well and good to have two systems until a crisis hits and some doctor plus the wrong sensor into the wrong device...

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

#206

Post by chungy »

jcranmer wrote: post #196
jsheard wrote: post #80

Earlier quoted context omitted.

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'm literally giving a talk next week who's first slide is essentially "Why IEEE 754 is not a sufficient description of floating-point semantics" and I'm sitting here trying to figure out what needs to be thrown out of the talk to make it fit the time slot. One of the most surprising things about floating-point is that very little is actually IEEE 754; most things are merely IEEE 754-ish, and there's a long tail of f…

The IEEE 754 standard has been updated several times, often by relaxing previous mandates in order to make various hardware implementations become compliant retroactively (eg, adding Intel's 80-bit floats as a standard floating point size).

It'll be interesting if the "-ish" bits are still "-ish" with the current standard.

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

#207

Post by kmeisthax »

Negitivefrags wrote: post #185
bee_rider wrote: post #171

Earlier quoted context omitted.

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.

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.

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

#208

Post by stkdump »

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.

I mean practically speaking in C++ we have (it just hasn't made it to the standard):

1. char 8 bit

2. short 16 bit

3. int 32 bit

4. long long 64 bit

5. arithmetic is 2s complement

6. IEEE floating point (float is 32, double is 64 bit)

Along with other stuff like little endian, etc.

Some people just mistakenly think they can't rely on such stuff, because it isn't in the standard. But they forget that having an ISO standard comes on top of what most other languages have, which rely solely on the documentation.

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

#209

Post by billti »

bobmcnamara wrote: post #46
wvenable wrote: post #32

Earlier quoted context omitted.

As an abstraction on the size of a CPU register, it really turned out to be more confusing than useful.

Is it 32 or 64 bits on ARM64? Why not both?

ARM64 has a 32-bit word, even though the native pointer size and general register size is 64 bits. To access just the lower 32 bits of a register Xn you refer to it as Wn.

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

#210

Post by atq2119 »

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?

Computers are not beings with 10 fingers that can be up or down.

Powers of two are more natural in a binary computer. Then add the fact that 8 is the smallest power of two that allows you to fit the Latin alphabet plus most common symbols as a character encoding.

We're all about building towers of abstractions. It does make sense to aim for designs that are natural for humans when you're closer to the top of the stack. Bytes are fairly low down the stack, so it makes more sense for them to be natural to computers.

Post reply on HN