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

351–357 of 357 posts

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

#351

Post by kazinator »

pezezin wrote: post #346
kazinator wrote: post #326

Earlier quoted context omitted.

Some 32 bit thing being the go to integer type flies against software engineering and CS. It's going to get expensive on a machine that has only 64 bit integers, which must be accessed on 8 byte aligned boundaries.

And which machine is that? The only computers that I can think of with only 64-bit integers are the old Cray vector supercomputers, and they used word addressing to begin with.

It will likely be common in another 25 to 30 years, as 32 bit systems fade into the past.

Therefore, declaring that int32 is the go to integer type is myopic.

Forty years ago, a program like this could be run on a 16 bit machine (e.g. MS-DOS box):

  #include 

  int main(int argc, char **argv)
  {
    while (argc-- > 0)
      puts(*argv++);
    return 0;
  }
int was 16 bits. That was fine; you would never pass anywhere near 32000 arguments to a program.

Today, that same program does the same thing on a modern machine with a wider int.

Good thing that some int16 had not been declared the go to integer type.

Rust's integer types are deliberately designed (by people who know better) in order to be appealing to people who know shit all about portability and whose brains cannot handle reasoning about types with a bit of uncertainty.

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

#352

Post by kazinator »

itishappy wrote: post #291
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.

Except defining your types with arbitrary names is still hardware dependent, it's just now something you have to remember or guess. Can you remember the name for a 128 bit integer in your preferred language off the top of your head? I can intuit it in Rust or Zig (and many others). In D it's... oh... it's int128. https://dlang.org/phobos/std_int128.html https://github.com/dlang/phobos/blob/master/std/int128.d

In C it will almost certainly be int128_t, when standardized. 128 bit support is currently a compiler extension (found in GCC, Clang and others).

A type that provides a 128 bit integer exactly should have 128 in its name.

That is not the argument at all.

The problem is only having types like that, and stipulating nonsense like that the primary "go to" integer type is int32.

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

#353

Post by stkdump »

mort96 wrote: post #343
stkdump wrote: post #334

Earlier quoted context omitted.

I don't think this is true. The target audience of the ISO standard is the implementers of compilers and other tools around the language. Even the people involved in creating it make that clear by publishing other material like the core guidelines, conference talks, books, online articles, etc., which are targeted to the users of the language.

Core guidelines, conference talks, books, online articles, etc. are not authoritative. If I really want to know if my C code is correct C, I consult the standard. If the standard and an online article disagrees, the article is wrong, definitionally.

Correction: if you want to know if your compiler is correct, you look at the ISO standard. But even as a compiler writer, the ISO standard is not exhaustive. For example the ISO standard doesn't define stuff like include directories, static or dynamic linking, etc.

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

#354

Post by pezezin »

kazinator wrote: post #351
pezezin wrote: post #346

Earlier quoted context omitted.

And which machine is that? The only computers that I can think of with only 64-bit integers are the old Cray vector supercomputers, and they used word addressing to begin with.

It will likely be common in another 25 to 30 years, as 32 bit systems fade into the past. Therefore, declaring that int32 is the go to integer type is myopic. Forty years ago, a program like this could be run on a 16 bit machine (e.g. MS-DOS box): #include int main(int argc, char **argv) { while (argc-- > 0) puts(*argv++); return 0; } int was 16 bits. That was fine; you would never pass anywhere near 32000 arguments…

Sorry, but I fail to see where the problem is. Any general purpose ISA designed in the past 40 years can handle 8/16/32 bit integers just fine regardless of the register size. That includes the 64-bit x86-64 or ARM64 from which you are typing.

The are a few historical architectures that couldn't handle smaller integers, like the first generation Alpha, but:

    a) those are long dead.

    b) hardware engineers learnt from their mistake and no modern general purpose architecture has repeated it (specialized architectures like DSP and GPU are another story though).

    c) worst case scenario, you can simulate it in software.

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

#356

Post by selimthegrim »

speedgoose wrote: post #202
jcranmer wrote: post #196

Earlier quoted context omitted.

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…

I'm interested by your future talk, do you plan to publish a video or a transcript?

I too would like to see it.

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

#357

Post by harry8 »

BoringTimesGang wrote: post #250
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.

Hahaha, you're including Bjarne in that sweeping generalization? C++ has long had a culture problem revolving around arrogance an belittling others, maybe it is growing out of it?

I would point out that for any language, if one has to follow the standards committee closely to be an effective programmer in that language, complexity is likely to be an issue. Fortunately in this case it probably isn't required.

I see garbage collection came in c++11 and has now gone. Would following that debacle make many or most c++ programmers more effective?

Post reply on HN