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

331–340 of 357 posts

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

#331

Post by WalterBright »

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

It was actually supposed to be `cent` and`ucent`, but we needed a library type to stand in for it at the moment.

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

#333

Post by whs »

renox wrote: post #296
Cloudef wrote: post #237

Earlier quoted context omitted.

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

u0?? Why?

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.

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

#334

Post by stkdump »

mort96 wrote: post #325
stkdump wrote: post #313

Earlier quoted context omitted.

You are aware that D and rust and all the other languages this is being compared to don't even have an ISO standard, right?

Yeah, so their documentation serves as the authority on how you're supposed to write your code for it to be "correct D" or "correct Rust". The compiler implementors write their compilers against the documentation (and vice versa). That documentation is clear on these things. In C, the ISO standard is the authority on how you're supposed to write your code for it to be "correct C". The compiler implementors write thei…

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.

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

#335

Post by speedyjay »

josephg wrote: post #321
speedyjay wrote: post #316

Earlier quoted context omitted.

https://pastebin.com/raw/D7p7mRLK My comment in a pastebin. HN doesn't like unicode. You need this crate to deal with it in Rust, it's not part of the base libraries: https://crates.io/crates/unicode-segmentation The languages that have this kind of feature built-in in the standard library, to my knowledge, are Swift, JavaScript, C# and Java. Swift is the only one, of those four, that treat operating on graphemes as…

For context, it looks like you’re talking about iterating by grapheme clusters. I understand how iterating through a string by grapheme clusters is convenient for some applications. But it’s far from obvious to me that doing so should be the language’s default. Dealing with grapheme clusters requires a Unicode database, which needs to live somewhere and needs to be updated continuously as Unicode grows. (Should rust…

This was not meant as criticism for rust in particular (though, while it shouldn't be the default behavior of strings in a systems language, surely at least the official implementation of a wrapper should exist?), but high level languages with ton of baggage like python should definitely provide the correct way to handle strings, the amount of software I've seen that are unable to properly handle strings because the language didn't provide the required grapheme handling and the developer was also not aware of the reality of graphemes and unicode..

You mention terminals, yes, it's one of the area where graphemes are an absolute must, but pretty much any time you are going to do something to text like deciding "I am going to put a linebreak here so that the text doesn't overflow beyond the box, beyond this A4 page I want to print, beyond the browser's window" grapheme handling is involved.

Any time a user is asked to input something too. I've seen most software take the "iterate over characters" approach to real time user input and they break down things like those emojis into individual components whenever you paste something in.

For that matter, backspace doesn't work properly on software you would expect to do better than that. Put the emoji from my pastebin in Microsoft Edge's search/url bar, then hit backspace, see what happens. While the browser displays the emoji correctly, the input field treats it the way Python segments it in my example: you need to press backspace 7 times to delete it. 7 times! Windows Terminal on the other hand has the quirk of showing a lot of extra spaces after the emoji (despite displaying the emoji correctly too) and will also require 11 backspace to delete it.

Notepad handles it correctly: press backspace once, it's deleted, like any normal character.

> Of those 3 iteration methods, I’ve personally used UTF8 encoding the most and grapheme clusters the least.

This doesn't say anything about grapheme clusters being useless. I've cited examples of popular software doing the wrong thing precisely because, like you, they didn't iterate over grapheme clusters. That you never use grapheme iteration might say more about you than it says about grapheme iteration being unneeded.

The dismissiveness over more sane string handling as a standard is not unlike C++ developers pretending that developers are doing the right thing with memory management so we don't need a GC (or rust's ownership paradigm). Nonsense.

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

#336

Post by __turbobrew__ »

epcoa wrote: post #300
__turbobrew__ wrote: post #204

Earlier quoted context omitted.

I mean you should be building life critical medical devices on top of an operating system like QNX or vxworks which are much more stable and simpler.

Regulations are complex, but not every medical device or part of it is "life critical". There are plenty of regulated medical devices floating around running Linux, often based on Yocto. There is some debate in the industry about the particulars of this SOUP (software of unknown provenance) in general, but the mere idea of Linux in a medical device is old news and isn't crackpot or anything. The goal for this guy see…

> You can't use non-typesafe junk when lives are on the line.

Their words, not mine. If lives are on the line you probably shouldn’t be using linux in your medical device. And I hope my life never depends on a medical device running linux.

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

#337

Post by Animats »

AnimalMuppet wrote: post #307
AlienRobot wrote: post #305

Earlier quoted context omitted.

I see. I never realized that machines needed to be random number of bits because they couldn't do double-precision so it was easier to make the word larger and do "half" precision instead. Thanks a lot for your explanation, but does that mean "byte" is any amount of data that can be fetched in a given mode in such machines? e.g. you have 6-bit, 9-bit, 12-bit, and 18-bit bytes in a 36-bit machine in sixth-word mode, q…

I don't think so. In the "normal" world, you can't address anything smaller than a byte, and you can only address in increments of a byte. A "word" is usually the size of the integer registers in the CPU. So the 36-bit machine would have a word size of 36 bits, and either six-bit bytes or nine-bit bytes, depending on how it was configured. At least, if I understood all of this...

One PDP-10 operating system stored five 7-bit characters in one 36-bit word. This was back when memory cost a million dollars a megabyte in the 1970s.

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

#338

Post by adrian_b »

stephencanon wrote: post #288
chungy wrote: post #206

Earlier quoted context omitted.

The IEEE 754 standard has been updated several times, often by relaxing previous mandates in order to make various hardware implementations become compliant retroactively (eg, adding Intel's 80-bit floats as a standard floating point size). It'll be interesting if the "-ish" bits are still "-ish" with the current standard.

The first 754 standard (1985) was essentially formalization of the x87 arithmetic; it defines a "double extended" format. It is not mandatory: > Implementations should support the extended format corresponding to the widest basic format supported. _if_ it exists, it is required to have at least as many bits as the x87 long double type.¹ The language around extended formats changed in the 2008 standard, but the meanin…

The first 754 standard has still removed some 8087 features, mainly the "projective" infinity and it has slightly changed the definition of the remainder function, so it was not completely compatible with 8087.

Intel 80387 was made compliant with the final standard and by that time there were competing FPUs also compliant with the final standard, e.g. Motorola 68881.

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

#339

Post by adrian_b »

tialaramex wrote: post #248
conradev wrote: post #178

Earlier quoted context omitted.

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

The IEEE FP16 format is what is useful in graphics applications, e.g. for storing color values.

The Google BF16 format is useful strictly only for machine learning/AI applications, because its low precision is insufficient for anything else. BF16 has very low precision, but an exponent range equal to FP32, which makes overflows and underflows less likely.

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

#340

Post by josephg »

speedyjay wrote: post #335
josephg wrote: post #321

Earlier quoted context omitted.

For context, it looks like you’re talking about iterating by grapheme clusters. I understand how iterating through a string by grapheme clusters is convenient for some applications. But it’s far from obvious to me that doing so should be the language’s default. Dealing with grapheme clusters requires a Unicode database, which needs to live somewhere and needs to be updated continuously as Unicode grows. (Should rust…

This was not meant as criticism for rust in particular (though, while it shouldn't be the default behavior of strings in a systems language, surely at least the official implementation of a wrapper should exist?), but high level languages with ton of baggage like python should definitely provide the correct way to handle strings, the amount of software I've seen that are unable to properly handle strings because the…

Those are good examples! Notably, all of them are in reasonably low level, user-facing code.

Your examples are implementing custom text input boxes (Excel, Edge), line breaks while printing, and implementing a terminal application. I agree that in all of those cases, grapheme cluster segmentation is appropriate. But that doesn't make grapheme cluster based iteration "the correct way to handle strings". There's no "correct"! There are at least 3 different ways to iterate through a string, and different applications have different needs.

Good languages should make all of these options easy for programmers to use when they need them. Writing a custom input box? Use grapheme clusters. Writing a text based CRDT? Treat a string as a list of unicode codepoints. Writing an HTTP library? Treat the headers and HTML body as ASCII / opaque bytes. Etc.

I take the criticism that rust makes grapheme iteration harder than the others. But eh, rust has truly excellent crates for that within arms reach. I don't see any advantage in moving grapheme based segmentation into std. Well, maybe it would make it easier to educate idiot developers about this stuff. But there's no real technical reason. Its situationally useful - but less useful than lots of other 3rd party crates like rand, tokio and serde.

> like you, they didn't iterate over grapheme clusters. That you never use grapheme iteration might say more about you than it says about grapheme iteration being unneeded.

It says that in 30+ years of programming, I've never programmed a text input field from scratch. Why would I? That's the job of the operating system. Making my own sounds like a huge waste of time.

Post reply on HN