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

251–260 of 357 posts

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

#251

Post by heinrich5991 »

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

Permalink (press 'y' anywhere on GitHub): https://github.com/torvalds/linux/blob/4d939780b70592e0f4bc6....

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

#252

Post by heinrich5991 »

pezezin wrote: post #151
kazinator wrote: post #138

Earlier quoted context omitted.

> you have to mention the size explicitly It's unbelievably ugly. Every piece of code working with any kind of integer screams "I am hardware dependent in some way". E.g. in a structure representing an automobile, the number of wheels has to be some i8 or i16, which looks ridiculous. Why would you take a language in which you can write functional pipelines over collections of objects, and make it look like assembler.

If you don't care about the size of your number, just use isize or usize. If you do care, then isn't it better to specify it explicitly than trying to guess it and having different compilers disagreeing on the size?

Actually, if you don't care about the size of your small number, use `i32`. If it's a big number, use `i64`.

`isize`/`usize` should only be used for memory-related quantities — that's why they renamed from `int`/`uint`.

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

#253

Post by BoringTimesGang »

hyperhello wrote: post #95
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++ long ago crossed the line where making any change is more work than any benefit it could ever create.

This is such an odd thing to read & compare to how eager my colleagues are to upgrade the compiler to take advantage of new features. There's so much less need to specify types in situations where the information is implicitly available after C++ 20/17. So many boost libraries have been replaced by superior std versions.

And this has happened again and again on this enormous codebase that started before it was even called 'C++'.

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

#254

Post by BoringTimesGang »

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

Ah, I hope nobody ever uses that additional bit for additional encoding. That could cause all kinds of incompatibilities...

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

#255

Post by tialaramex »

meindnoch wrote: post #230
kmeisthax wrote: post #207

Earlier quoted context omitted.

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.

std::map is not a hash map. It's a tree map. It supports range queries, upper and lower bound queries. Quite useful for geometric algorithms.

Rust's BTreeMap, which is much closer to what std::map is, also requires Ord (ie types which claim to possess total order) for any key you can put in the map.

However, Ord is an ordinary safe trait. So while we're claiming to be totally ordered, we're allowed to be lying, the resulting type is crap but it's not unsafe. So as with sorting the algorithms inside these container types, unlike in C or C++ actually must not blow up horribly when we were lying (or as is common in real software, simply clumsy and mistaken)

The infinite loop would be legal (but I haven't seen it) because that's not unsafe, but if we end up with Undefined Behaviour that's a fault in the container type.

This is another place where in theory C++ gives itself license to deliver better performance at the cost of reduced safety but the reality in existing software is that you get no safety but also worse performance. The popular C++ compilers are drifting towards tacit acceptance that Rust made the right choice here and so as a QoI decision they should ship the Rust-style algorithms.

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

#256

Post by p_l »

Ballas wrote: post #217
Isamu wrote: post #166

Earlier quoted context omitted.

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.

That is so strange. If it were 9-bit bytes, that would make sense: 8bits+parity. Then a word is just 32bits+4 parity.

7 bits matches ASCII, so you can implement entire ASCII character set, and simultaneously it means you get to fit one more character per byte.

Using RADIX-50, or SIXBIT, you could fit more but you'd lose ASCII-compatibility

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

#257

Post by aydyn »

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…

can you give a brief example? Very intrigued.

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

#258

Post by eqvinox »

larsbrinkhoff wrote: post #214
asveikau wrote: post #114

Earlier quoted context omitted.

I think the pdp-10 could have 9 bit bytes, depending on decisions you made in the compiler. I notice it's hard to Google information about this though. People say lots of confusing, conflicting things. When I google pdp-10 byte size it says a c++ compiler chose to represent char as 36 bits.

PDP-10 byte size is not fixed. Bytes can be 0 to 36 bits wide. (Sure, 0 is not very useful; still legal.) I don't think there is a C++ compiler for the PDP-10. One of the C compiler does have a 36-bit char type.

Do you have any links/info on how that 0-bit byte worked? It sounds like just the right thing for a Friday afternoon read ;D

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

#259

Post by eqvinox »

seoulbigchris wrote: post #238
thamer wrote: post #130

Earlier quoted context omitted.

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?

Yes, trit is commonly used for ternary logic. "quit" I have never heard in such a context.

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

#260

Post by bregma »

elromulous wrote: post #124
poincaredisk wrote: post #110

Earlier quoted context omitted.

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

Technically the smallest addressable piece of memory is a word.

The difference between address A and address A+1 is one byte. By definition.

Some hardware may raise an exception if you attempt to retrieve a value at an address that is not a (greater than 1) multiple of a byte, but that has no bearing on the definition of a byte.

Post reply on HN