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

191–200 of 357 posts

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

#191

Post by ndesaulniers »

jfbastien wrote: post #143
MaulingMonkey wrote: post #47

Some people are still dealing with DSPs. https://thephd.dev/conformance-should-mean-something-fputc-a... Me? I just dabble with documenting an unimplemented "50% more bits per byte than the competition!" 12-bit fantasy console of my own invention - replete with inventions such as "UTF-12" - for shits and giggles.

Yes, I'm trying to figure out which are still relevant and whether they target a modern C++, or intend to. I've been asking for a few years and haven't gotten positive answers. The only one that been brought up is TI, I added info in the updated draft: https://isocpp.org/files/papers/D3477R1.html

> and would benefit from C23’s _BigInt

s/_BigInt/_BitInt/

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

#192

Post by forrestthewoods »

skissane wrote: post #85
forrestthewoods wrote: post #28

Earlier quoted context omitted.

Do UNIVACs care about modern C++ compilers? Do modern C++ compilers care about UNIVACs? Given that Wikipedia says UNIVAC was discontinued in 1986 I’m pretty sure the answer is no and no!

The UNIVAC 1108 (and descendants) mainframe architecture was not discontinued in 1986. The company that owned it (Sperry) merged with Burroughs in that year to form Unisys. The platform still exists, but now runs as a software emulator under x86-64. The OS is still maintained and had a new release just last year. Around the time of the merger the old school name “UNIVAC” was retired in a rebranding, but the platform…

That would be a resounding no then. Nice. So why are we talking about an obscure and irrelevant-to-the-discussion platform? Internet comments I swear.

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

#193

Post by pezezin »

kazinator wrote: post #152
pezezin wrote: post #151

Earlier quoted context omitted.

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?

A type called isize is some kind of size. It looks wrong for something that isn't a size.

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

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

#194

Post by davidgay »

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 was just unlucky, it standardised it's strings at the wrong time (when Unicode was 16-bit code points): Java was announced in May 1995, and the following comment from the Unicode history wiki page makes it clear what happened: "In 1996, a surrogate character mechanism was implemented in Unicode 2.0, so that Unicode was no longer restricted to 16 bits. ..."

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

#195

Post by smaudet »

__turbobrew__ wrote: post #163
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…

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 otherwise, legal or otherwise, and that insists upon updating and further breaking itself at regular intervals...

Unless you mean to talk maybe about some microkernel with a very simple graphical UI, which, sure yes, much less complexity...

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

#196

Post by jcranmer »

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'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 fiddly things that are different that make it only -ish.

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

#197

Post by notfed »

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…

Same deal with Rust.

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

#198

Post by sirsinsalot »

fourier54 wrote: post #183
basementcat wrote: post #177

Earlier quoted context omitted.

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_(inform…

That is a bit in information theory. It has nothing to do with the computer/digital engineering term being discussed here.

This comment I feel sure would repulse Shannon in the deepest way. A (digital, stored) bit, abstractly seeks to encode and make useful through computation the properties of information theory.

Your comment must be sarcasm or satire, surely.

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

#199

Post by jfbastien »

ndesaulniers wrote: post #191
jfbastien wrote: post #143

Earlier quoted context omitted.

Yes, I'm trying to figure out which are still relevant and whether they target a modern C++, or intend to. I've been asking for a few years and haven't gotten positive answers. The only one that been brought up is TI, I added info in the updated draft: https://isocpp.org/files/papers/D3477R1.html

> and would benefit from C23’s _BigInt s/_BigInt/_BitInt/

Dang, will fix when I get home! Thanks Nick, and hi!

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

#200

Post by Terr_ »

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…

> there's a long tail of fiddly things that are different that make it only -ish.

Perhaps a way to fill some time would be gradually revealing parts of a convoluted Venn diagram or mind-map of the fiddling things. (That is, assuming there's any sane categorization.)

Post reply on HN