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

241–250 of 357 posts

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

#241

Post by zombot »

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?

If your detector is sensitive enough, it could be just a single electron that's either present or absent.

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

#242

Post by pjmlp »

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

While I don't agree with not having unsigned as part of the primitive times, and look forward to Valhala fixing that, it was based on the experience most devs don't get unsigned arithmetic right.

"For me as a language designer, which I don't really count myself as these days, what "simple" really ended up meaning was could I expect J. Random Developer to hold the spec in his head. That definition says that, for instance, Java isn't -- and in fact a lot of these languages end up with a lot of corner cases, things that nobody really understands. Quiz any C developer about unsigned, and pretty soon you discover that almost no C developers actually understand what goes on with unsigned, what unsigned arithmetic is. Things like that made C complex. The language part of Java is, I think, pretty simple. The libraries you have to look up."

http://www.gotw.ca/publications/c_family_interview.htm

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

#243

Post by mjevans »

bee_rider wrote: post #172
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.

Hah. Why did they do that?

Which part of it?

8 bit tape? Probably the format the hardware worked in... not actually sure I haven't used real tapes but it's plausible.

36 bit per word computer? Sometimes 0..~4Billion isn't enough. 4 more bits would get someone to 64 billion, or +/- 32 billion.

As it turns out, my guess was ALMOST correct

https://en.wikipedia.org/wiki/36-bit_computing

Paraphrasing, legacy keying systems were based on records of up to 10 printed decimal digits of accuracy for input. 35 bits would be required to match the +/- input but 36 works better as a machine word and operations on 6 x 6 bit (yuck?) characters; or some 'smaller' machines which used a 36 bit larger word and 12 or 18 bit small words. Why the yuck? That's only 64 characters total, so these systems only supported UPPERCASE ALWAYS numeric digits and some other characters.

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

#244

Post by pjmlp »

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?"

GC API from C++11 was removed in C++23, understandibly so, given that it wasn't designed taking into account the needs of Unreal C++ and C++/CLI, the only two major variants that have GC support.

Exception specifications have been removed, although some want them back for value type exceptions, if that ever happens.

auto_ptr has been removed, given its broken design.

Now on the simplying side, not really, as the old ways still need to be understood.

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

#245

Post by pjmlp »

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.

It is one of my favourite languages, but I think it has already crossed over the complexity threshold PL/I was known for.

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

#246

Post by pjmlp »

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…

I got curious, there is a Wikipedia page describing what languages are currently available,

https://en.wikipedia.org/wiki/Unisys_OS_2200_programming_lan...

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

#248

Post by tialaramex »

conradev wrote: post #178
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 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

Note that this type (which Rust will/ does in nightly call "f16" and a C-like language would probably name "half") is not the only popular 16-bit floating point type, as some people want to have https://en.wikipedia.org/wiki/Bfloat16_floating-point_format

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

#249

Post by amelius »

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?

Depends on your physical media.

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

#250

Post by BoringTimesGang »

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?"

>haven't followed closely

Don't worry, most people complaining about C++ complexity don't.

Post reply on HN