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

341–350 of 357 posts

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

#341

Post by Dagonfly »

smaudet wrote: post #205
epcoa wrote: post #142

Earlier quoted context omitted.

Wow. https://theminimumyouneedtoknow.com/ https://lscs-software.com/LsCs-Roadmap.html "Many of us got our first exposure to Qt on OS/2 in or around 1987." Uh huh. > someone always has a use case; No he doesn't. He's just unhinged. The machines this dude bitches about don't even have a modern C++ compiler nor do they support any kind of display system relevant to Qt. They're never going to be a target for Qt. Further…

Yeah, I think many of their arguments are not quite up to snuff. I would be quite interested how 1s compliment is faster, it is simpler and thus the hardware could be faster, iff you figure out how to deal with the drawbacks like -0 vs +0 (you could do it in hardware pretty easily...) Buuuut then the Unisys thing. Like you say they dont make processors (for the market) and themselves just use Intel now...and even if…

> it is simpler and thus the hardware could be faster

Is it though? With twos compliment ADD and SUB are the same hardware for unsigned and signed. MUL/IMUL is also the same for the lower half of the result (i.e. 32bit × 32bit = 32bit). So you're ALU and ISA are simple and flexible by design.

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

#343

Post by mort96 »

stkdump wrote: post #334
mort96 wrote: post #325

Earlier quoted context omitted.

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.

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.

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

#344

Post by [deleted] »

__turbobrew__ wrote: post #336
epcoa wrote: post #300

Earlier quoted context omitted.

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.

[deleted]

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

#345

Post by eps »

WalterBright wrote: post #329
eps wrote: post #308

Earlier quoted context omitted.

That's a bit self-pat-on-the-back-ish, isn't it, Mr. Bright, the author of D language? :)

Of course! Over the years I've known some engineers who, as a side project, wrote some great software. Nobody was interested in it. They'd come to me and ask why that is? I suggest writing articles about their project, and being active on the forums. Otherwise, who would ever know about it? They said that was unseemly, and wouldn't do it. They wound up sad and bitter. The "build it and they will come" is a stupid Hol…

> https://www.digitalmars.com/articles/C-biggest-mistake.html

To be fair, this one lies on the surface for anyone trying to come up with an improved C. It's one of the first things that gets corrected in nearly all C derivatives.

> C++ has already adopted many ideas from D.

Do you have a list?

Especially for the "adopted from D" bit rather than being a evolutionary and logical improvement to the language.

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

#346

Post by pezezin »

kazinator wrote: post #326
heinrich5991 wrote: post #319

Earlier quoted context omitted.

> If you use i32, it looks like you care. In Rust, that's not really the case. `i32` is the go-to integer type. `isize` on the other hand would look really weird in code — it's an almost unused integer type. I also prefer having integers that don't depend on the machine I'm running them on.

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.

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

#347

Post by epcoa »

Dagonfly wrote: post #341
smaudet wrote: post #205

Earlier quoted context omitted.

Yeah, I think many of their arguments are not quite up to snuff. I would be quite interested how 1s compliment is faster, it is simpler and thus the hardware could be faster, iff you figure out how to deal with the drawbacks like -0 vs +0 (you could do it in hardware pretty easily...) Buuuut then the Unisys thing. Like you say they dont make processors (for the market) and themselves just use Intel now...and even if…

> it is simpler and thus the hardware could be faster Is it though? With twos compliment ADD and SUB are the same hardware for unsigned and signed. MUL/IMUL is also the same for the lower half of the result (i.e. 32bit × 32bit = 32bit). So you're ALU and ISA are simple and flexible by design.

For calculations, of course it’s not simpler or faster. At best, you could probably make hardware where it’s close to a wash.

One that lectures on the importance of college you would think would demonstrate the critical thinking skills to ask themselves why the top supercomputers use 2’s complement like everyone else.

The only aspect of 1’s or sign mag that is simpler is in generation. If you have a simple ADC that gives you a magnitude based on a count and a direction, it is trivial to just output that directly. 1’s I guess is not too much harder with XORs (but what’s the point?). 2’s requires some kind of ripple carry logic, the add 1 is one way, there are some other methods you can work out but still more logic than sign-mag. This is pretty much the only place where non 2’s complement has any advantage. Finally for an I2C or SPI sensor like a temp sensor it is more likely you will get none of the above and have some asymmetric scale. Anybody in embedded bloviating on this ought to know.

In his ramblings the mentions of packed decimal (BCD) are a nice touch. C, C++ has never supported that to begin with so I have no idea why that must also be “considered”.

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

#348

Post by Narishma »

MaulingMonkey wrote: post #47

Some people are still dealing with DSPs. https://thephd.dev/conformance-should-mean-something-fputc-a... Me? I just dabble with documenting an unimplemented "50% more bits per byte than the competition!" 12-bit fantasy console of my own invention - replete with inventions such as "UTF-12" - for shits and giggles.

Didn't the PDP-8 have 12-bit bytes?

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

#349

Post by bmacho »

WalterBright wrote: post #322
bmacho wrote: post #280

Earlier quoted context omitted.

> D made a great leap forward > 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! Nah. It is actually pretty bad. Type names with explicit sizes (u8, i32, etc) are way better in every way.

> Type names with explicit sizes (u8, i32, etc) are way better in every way Until one realizes that the entire namespace of i nnn , u nnn , f nnn , etc., is reserved.

You are right, they come with a cost.

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

#350

Post by euroderf »

thamer wrote: post #130
gerdesj wrote: post #100

Earlier quoted context omitted.

"1. bytes are 8 bits" How big is a bit?

This doesn't feel like a serious question, but in case this is still a mystery to you… the name bit is a portmanteau of binary digit , and as indicated by the word "binary", there are only two possible digits that can be used as values for a bit: 0 and 1.

So shouldn't a two-state datum be a twit ?
Post reply on HN