2 ms·

Leaving out UB, what is the size of an "int"? Any of: 16bit, 32bit, 64bit is correct. However I'm absolutely certain the code you write for an 8bit microcontrol

Leaving out UB, what is the size of an "int"? Any of: 16bit, 32bit, 64bit is correct. However I'm absolutely certain the code you write for an 8bit microcontroller is a lot different from your 64bit server, so why is this language pretending to scale like that? Yeah you can now write "uint8_t" instead of "char", but the point is that the ecosystem is a landmine and all the maimed people are shamed with "you should have read the 400 page map" At risk of sounding crazy what if we just took this undefined behavior and just defined it? Theres like maybe 100 cpu ISAs in the world we care about, and the web and the transitory nature of tech had made legacy support kinda useless. Life would probably be simpler if we just said "ok heres how these constructs work" and just removed the ambiguity

passivate 5y ago
> Yeah you can now write "uint8_t" instead of "char", but the point is that the ecosystem is a landmine and all the maimed people are shamed with "you should have read the 400 page map" You're criticizing syntax from 30 years ago. Yes, the backwards compatibility (to me) is a BONUS. I would not want to junk working code that I paid for, just so I can use uint8_t. You have the option to begin a slow migration of old code into more modern code - without paying the massive cost of re-writing from scratch. I guess I am not able to connect with your criticism since it is far removed from my original point - What are examples of normal C++ syntax where the language screws you over with UB? Its a honest question - I'm not longer a C++ dev but I am curious to know what people are talking about.
- overgard 5y ago
  I'm not against backwards compatibility, I just think leaving primitive sizes up to shrug emoji wasn't brilliant Man reasons where C syntax has left me out to dry? Well I once spent a week on a deadline debugging a pointer overflow, where it only happened when the game was fullscreen and not debuggable (circa 2005). Even modern C++ is awful though. I fixed a bug a while ago where an "auto&" was just an "auto", and caused the entire scene graph to get copied and then crash.

passivate 5y ago

> Yeah you can now write "uint8_t" instead of "char", but the point is that the ecosystem is a landmine and all the maimed people are shamed with "you should have read the 400 page map" You're criticizing syntax from 30 years ago. Yes, the backwards compatibility (to me) is a BONUS. I would not want to junk working code that I paid for, just so I can use uint8_t. You have the option to begin a slow migration of old code into more modern code - without paying the massive cost of re-writing from scratch. I guess I am not able to connect with your criticism since it is far removed from my original point - What are examples of normal C++ syntax where the language screws you over with UB? Its a honest question - I'm not longer a C++ dev but I am curious to know what people are talking about.

overgard 5y ago
I'm not against backwards compatibility, I just think leaving primitive sizes up to shrug emoji wasn't brilliant Man reasons where C syntax has left me out to dry? Well I once spent a week on a deadline debugging a pointer overflow, where it only happened when the game was fullscreen and not debuggable (circa 2005). Even modern C++ is awful though. I fixed a bug a while ago where an "auto&" was just an "auto", and caused the entire scene graph to get copied and then crash.