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

Re:C++ proposal: There are 8 bits in a byte by Laremere on Thursday October 17, 2024 @10:31PM (#41875878)

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 std.math.add(), which returns an error on overflow.

6. f16, f32, f64, f80, and f128 are the respective but length IEEE floating point types.

The question of the length of a byte doesn't even matter. If someone wants to compile to machine whose bytes are 12 bits, just use u12 and i12.

[ Parent | on HN ]

Re:C++ proposal: There are 8 bits in a byte by __turbobrew__ on Thursday October 17, 2024 @11:03PM (#41876011)

This is the way.

[ Parent | on HN ]

Re:C++ proposal: There are 8 bits in a byte by Spivak on Thursday October 17, 2024 @11:03PM (#41876015)

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

[ Parent | on HN ]

Re:C++ proposal: There are 8 bits in a byte by dullcrisp on Friday October 18, 2024 @12:00AM (#41876229)

You think no one checks if their arithmetic overflows?

[ Parent | on HN ]

Re:C++ proposal: There are 8 bits in a byte by Spivak on Friday October 18, 2024 @12:32AM (#41876357)

I'm sure it's not literally no one but I bet the percent of additions that have explicit checks for overflow is for all practical purposes indistinguishable from 0.

[ Parent | on HN ]

Re:C++ proposal: There are 8 bits in a byte by nox101 on Friday October 18, 2024 @02:06AM (#41876729)

Lots of secure code checks for overflow

    fillBufferWithData(buffer, data, offset, size)

You want to know that offset + size don't wrap past 32bits (or 64) and end up with nonsense and a security vulnerability.

[ Parent | on HN ]

Re:C++ proposal: There are 8 bits in a byte by notfed on Friday October 18, 2024 @01:00AM (#41876480)

Same deal with Rust.

[ Parent | on HN ]

Re:C++ proposal: There are 8 bits in a byte by loup-vaillant on Friday October 18, 2024 @07:39AM (#41878431)

I've heard that Rust wraps around by default?

[ Parent | on HN ]

Re:C++ proposal: There are 8 bits in a byte by Measter on Friday October 18, 2024 @08:05AM (#41878612)

Rust has two possible behaviours: panic or wrap. By default debug builds with panic, release builds with wrap. Both behaviours are 100% defined, so the compiler can't do any shenanigans.

There are also helper functions and types for unchecked/checked/wrapping/saturating arithmetic.

[ Parent | on HN ]

Re:C++ proposal: There are 8 bits in a byte by mort96 on Friday October 18, 2024 @02:48AM (#41876942)

Eh I like the nice names. Byte=8, short=16, int=32, long=64 is my preferred scheme when implementing languages. But either is better than C and C++.

[ Parent | on HN ]

Re:C++ proposal: There are 8 bits in a byte by shiomiru on Friday October 18, 2024 @07:49AM (#41878505)

It would be "nice" if not for C setting a precedent for these names to have unpredictable sizes. Meaning you have to learn the meaning of every single type for every single language, then remember which language's semantics apply to the code you're reading. (Sure, I can, but why do I have to?)

[ui][0-9]+ (and similar schemes) on the other hand anybody can understand at the first glance.

[ Parent | on HN ]

Re:C++ proposal: There are 8 bits in a byte by Cloudef on Friday October 18, 2024 @04:02AM (#41877281)

Zig allows any uX and iX in the range of 1 - 65,535, as well as u0

[ Parent | on HN ]

Re:C++ proposal: There are 8 bits in a byte by renox on Friday October 18, 2024 @11:22AM (#41880263)

u0?? Why?

[ Parent | on HN ]

Re:C++ proposal: There are 8 bits in a byte by xigoi on Friday October 18, 2024 @11:55AM (#41880597)

To avoid corner cases in auto-generated code?

[ Parent | on HN ]

Re:C++ proposal: There are 8 bits in a byte by Cloudef on Friday October 18, 2024 @11:01PM (#41885321)

To represent 0 without actually storing it in memory

[ Parent | on HN ]

Re:C++ proposal: There are 8 bits in a byte by whs on Friday October 18, 2024 @11:35PM (#41885460)

Sounds like zero-sized types in Rust, where it is used as marker types (eg. this struct own this lifetime). It also can be used to turn a HashMap into a HashSet by storing zero sized value. In Go a struct member of [0]func() (an array of function, with exactly 0 members) is used to make a type uncomparable as func() cannot be compared.

[ Parent | on HN ]

Re:C++ proposal: There are 8 bits in a byte by Someone on Friday October 18, 2024 @07:10AM (#41878278)

LLVM has:

i1 is 1 bit

i2 is 2 bits

i3 is 3 bits

…

i8388608 is 2^23 bits

(https://llvm.org/docs/LangRef.html#integer-type)

On the other hand, it doesn’t make a distinction between signed and unsigned integers. Users must take care to use special signed versions of operations where needed.

[ Parent | on HN ]