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

221–230 of 357 posts

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

#221

Post by mort96 »

stkdump wrote: post #208
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.

I mean practically speaking in C++ we have (it just hasn't made it to the standard): 1. char 8 bit 2. short 16 bit 3. int 32 bit 4. long long 64 bit 5. arithmetic is 2s complement 6. IEEE floating point (float is 32, double is 64 bit) Along with other stuff like little endian, etc. Some people just mistakenly think they can't rely on such stuff, because it isn't in the standard. But they forget that having an ISO sta…

> (it just hasn't made it to the standard)

That's the problem

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

#222

Post by mort96 »

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

How is rand() broken? It seems to produce random-ish values, which is what it's for. It obviously doesn't produce cryptographically secure random values, but that's expected (and reflects other languages' equivalent functions). For a decently random integer that's quick to compute, rand() works just fine.

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

#223

Post by js8 »

Nothing to do with C++, but:

I kinda like the idea of 6-bit byte retro-microcomputer (resp. 24-bit, that would be a word). Because microcomputers typically deal with small number of objects (and prefer arrays to pointers), it would save memory.

VGA was 6-bit per color, you can have a readable alphabet in 6x4 bit matrix, you can stuff basic LISP or Forth language into 6-bit alphabet, and the original System/360 only had 24-bit addresses.

What's there not to love? 12MiB of memory, with independently addressable 6-bits, should be enough for anyone. And if it's not enough, you can naturally extend FAT-12 to FAT-24 for external storage. Or you can use 48-bit pointers, which are pretty much as useful as 64-bit pointers.

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

#224

Post by kazinator »

pezezin wrote: post #193
kazinator wrote: post #152

Earlier quoted context omitted.

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

Nope! Because then you will also define an alias, and Suzy will define an alias, and Bob will define an alias, ...

We should all agree on int and uint; not some isize nonsense, and not bobint or suzyint.

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

#225

Post by mort96 »

kreco wrote: post #39

I'm totally fine with enforcing that int8_t == char == 8-bits, however I'm not sure about spreading the misconception that a byte is 8-bits. A byte with 8-bits is called an octet. At the same time, a `byte` is already an "alias" for `char` since C++17 anyway[1]. [1] https://en.cppreference.com/w/cpp/types/byte

Nah, a byte is 8 bits.

This is a normative statement, not a descriptive statement.

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

#226

Post by weinzierl »

This is an egoistical viewpoint, but if I want 8 bits in a byte I have plenty of choices anyway - Zig, Rust, D, you name it. Should the need for another byte width come up, either for past or future architectures C and C++ are my only practical choice.

Sure, it is selfish to expect C and C++ do the dirty work, while more modern languages get away skimping on it. On the other hand I think especially C++ is doing itself a disservice trying to become a kind of half-baked Rust.

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

#227

Post by ptsneves »

jfbastien wrote: post #190
Negitivefrags wrote: post #185

Earlier quoted context omitted.

It can be harmful. In GCC while compiling a 32 bit executable, making an std::map can cause infinite loops or crashes in your program. This is because when you insert a value into the map, it has 80 bit precision, and that number of bits is used when comparing the value you are inserting during the traversal of the tree. After the float is stored in the tree, it's clamped to 32 bits. This can cause the element to be…

10 years ago, a coworker had a really hard time root-causing a bug. I shoulder-debugged it by noticing the bit patterns: it was a miscompile of LLVM itself by GCC, where GCC was using an x87 fldl/fstpl move for a union { double; int64; }. The active member was actually the int64, and GCC chose FP moved based on what was the first member of the union... but the int64 happened to be the representation of SNaN, so the i…

It also affected eMacs compilation and the fix is in the trunk now.

Wow 11 years for such a banal minimal code trigger. I really don’t quiet understand how we can have the scale of infrastructure in operation when this kind of infrastructure software bugs exist. This is not just gcc. All the working castle of cards is an achievement by itself and also a reminder that good enough is all that is needed.

I also highly doubt you could get a 1 in 1000 developers to successfully debug this issue were it happening in the wild, and much smaller to actually fix it.

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

#228

Post by loup-vaillant »

js8 wrote: post #223

Nothing to do with C++, but: I kinda like the idea of 6-bit byte retro-microcomputer (resp. 24-bit, that would be a word). Because microcomputers typically deal with small number of objects (and prefer arrays to pointers), it would save memory. VGA was 6-bit per color, you can have a readable alphabet in 6x4 bit matrix, you can stuff basic LISP or Forth language into 6-bit alphabet, and the original System/360 only h…

Or you can have 8 bit bytes, and 3 byte words. That’s still 24 bits.

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

#229

Post by jclulow »

kazinator wrote: post #224
pezezin wrote: post #193

Earlier quoted context omitted.

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

Nope! Because then you will also define an alias, and Suzy will define an alias, and Bob will define an alias, ... We should all agree on int and uint ; not some isize nonsense, and not bobint or suzyint .

Alas, it's pretty clear that we won't!

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

#230

Post by meindnoch »

kmeisthax wrote: post #207
Negitivefrags wrote: post #185

Earlier quoted context omitted.

It can be harmful. In GCC while compiling a 32 bit executable, making an std::map can cause infinite loops or crashes in your program. This is because when you insert a value into the map, it has 80 bit precision, and that number of bits is used when comparing the value you are inserting during the traversal of the tree. After the float is stored in the tree, it's clamped to 32 bits. This can cause the element to be…

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.
Post reply on HN