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

151–160 of 357 posts

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

#151

Post by pezezin »

kazinator wrote: post #138
jltsiren wrote: post #108

Earlier quoted context omitted.

I like the Rust approach more: usize/isize are the native integer types, and with every other numeric type, you have to mention the size explicitly. On the C++ side, I sometimes use an alias that contains the word "short" for 32-bit integers. When I use them, I'm explicitly assuming that the numbers are small enough to fit in a smaller than usual integer type, and that it's critical enough to performance that the ass…

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

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

#152

Post by kazinator »

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?

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

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

#153

Post by corysama »

Taniwha wrote: post #89
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've worked on a machine with 9-bit bytes (and 81-bit instructions) and others with 6-bit ones - nether has a C compiler

The Nintendo64 had 9-bit RAM. But, C viewed it as 8 bit. The 9th bit was only there for the RSP (GPU).

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

#154

Post by AlexandrB »

38 wrote: post #17

the fact that this isn't already done after all these years is one of the reasons why I no longer use C/C++. it takes years and years to get anything done, even the tiniest, most obvious drama free changes. contrast with Go, which has had this since version 1, in 2012: https://pkg.go.dev/builtin@go1#byte

Don't worry, 20 years from now Go will also be struggling to change assumptions baked into the language in 2012.

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

#155

Post by __turbobrew__ »

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…

This is the way.

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

#156

Post by Spivak »

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…

How does 5 work in practice? Surely no one is actually checking if their arithmetic overflows, especially from user-supplied or otherwise external values. Is there any use for the normal +?

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

#157

Post by kstrauser »

tetron wrote: post #76
SCUSKU wrote: post #34

Earlier quoted context omitted.

Henceforth, it follows that a doublesnack is called a lunch. And a quadruplesnack a fourthmeal.

There's only one right answer: Nybble - 4 bits Byte - 8 bits Snyack - 16 bits Lyunch - 32 bits Dynner - 64 bits

In the spirit of redefining the kilobyte, we should define byte as having a nice, metric 10 bits. An 8 bit thing is obviously a bibyte. Then power of 2 multiples of them can include kibibibytes, mebibibytes, gibibibytes, and so on for clarity.

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

#158

Post by stephencanon »

FooBarBizBazz wrote: post #127
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...

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.

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

#159

Post by asveikau »

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.

Depends on your definition of addressable.

Lots of CISC architectures allow memory accesses in various units even if they call general-purpose-register-sized quantities "word".

Iirc the C standard specifies that all memory can be accessed via char*.

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

#160

Post by Spivak »

kazinator wrote: post #138
jltsiren wrote: post #108

Earlier quoted context omitted.

I like the Rust approach more: usize/isize are the native integer types, and with every other numeric type, you have to mention the size explicitly. On the C++ side, I sometimes use an alias that contains the word "short" for 32-bit integers. When I use them, I'm explicitly assuming that the numbers are small enough to fit in a smaller than usual integer type, and that it's critical enough to performance that the ass…

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

Is it any better calling it an int where it's assumed to be an i32 and 30 of the bits are wasted.
Post reply on HN