4 ms·

For example, incrementing an int until it overflows.

passivate 5y ago
My point was what are examples of normal C++ code where the language obviously deviates from the intention of the programmer and screws them over with undefined behavior. I don't see how any programmer can "intend" to use a data-type assuming an infinite range - or assuming specific wrapping behavior that was never guaranteed to them by the language. If a programmer is unaware that language data types have finite ranges and/or specific wrapping behavior then that is a problem that can be easily solved with training.
- ModernMech 5y ago
  > If a programmer is unaware that language data types have finite ranges and/or specific wrapping behavior then that is a problem that can be easily solved with training. The thing is that everyone recognizes this and yet entire categories of bugs that are easily caught with appropriate language design and tooling nonetheless persist in C and C++. Yes, a programmer who does not understand the footguns involved with e.g. integer overflows can be trained to understand them and avoid them. But for every one you train, there will always be another novice programming ready and willing to use the footguns. And even if you do train every last one and every new one, they still have to practice discipline and be vigilant forever more to avoid these problems. Discipline doesn't scale. It's far better to enforce good behavior at the language level, rather than expecting you'll be able to train your way around these issues.
  - passivate 5y ago
    It will be difficult to program in any language if one believes that you can store an infinite number series in a fixed data type like int. It's like thinking a hard disk can store infinite data.
    - Etherlord87 5y ago
      Yes, but the problem in a different language comes down to an error message. In C you have UB and it's not defined what you have to expect, which makes it harder to find the cause of an error once it happens.
- overgard 5y ago
  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.

My point was what are examples of normal C++ code where the language obviously deviates from the intention of the programmer and screws them over with undefined behavior. I don't see how any programmer can "intend" to use a data-type assuming an infinite range - or assuming specific wrapping behavior that was never guaranteed to them by the language. If a programmer is unaware that language data types have finite ranges and/or specific wrapping behavior then that is a problem that can be easily solved with training.

ModernMech 5y ago
> If a programmer is unaware that language data types have finite ranges and/or specific wrapping behavior then that is a problem that can be easily solved with training. The thing is that everyone recognizes this and yet entire categories of bugs that are easily caught with appropriate language design and tooling nonetheless persist in C and C++. Yes, a programmer who does not understand the footguns involved with e.g. integer overflows can be trained to understand them and avoid them. But for every one you train, there will always be another novice programming ready and willing to use the footguns. And even if you do train every last one and every new one, they still have to practice discipline and be vigilant forever more to avoid these problems. Discipline doesn't scale. It's far better to enforce good behavior at the language level, rather than expecting you'll be able to train your way around these issues.
- passivate 5y ago
  It will be difficult to program in any language if one believes that you can store an infinite number series in a fixed data type like int. It's like thinking a hard disk can store infinite data.
  - Etherlord87 5y ago
    Yes, but the problem in a different language comes down to an error message. In C you have UB and it's not defined what you have to expect, which makes it harder to find the cause of an error once it happens.
overgard 5y ago
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.