4 ms·

> Relying on integer overflow’s wrapping behavior is considered an error Your doc also says this. > I hear there are some who want to dilute the safety guaran

> Relying on integer overflow’s wrapping behavior is considered an error Your doc also says this. > I hear there are some who want to dilute the safety guarantees of Safe Rust Unfortunately, I don't use Rust at work. I can't talk about it anymore, either. I can't use an informal reference to reason about its actual behavior. At the end of the day, C++ puts food on the table. I try to improve C++ as much as possible, knowing that it is an imperfect language. C++ is heading into safe direction, and I'm sure C++26 will be able to provide more features to write code safely. Rust seriously need to add Function Overloading, Generics.

MaxBarraclough 5y ago
> I can't use an informal reference to reason about its actual behavior. I don't follow here. You can do that. There's a more formal reference too though. [0] > Relying on integer overflow’s wrapping behavior is considered an error Good point, I'd missed that. So, Rust strongly discourages relying on the wrapping behaviour of release builds. It seems to take the opposite approach that Java uses. In Java, you get wrapping arithmetic 'by default' (i.e. when using the arithmetic operators), and there are special functions that give throw-on-overflow behaviour (which almost no one uses). [1] In Rust, the arithmetic operators handle overflow either by wrapping or by panic, depending on build configuration, and if you deliberately want to overflow, there are special functions for that (i32::wrapping_add) which behave identically on Debug and Release builds. I believe Ada does something similar. > At the end of the day, C++ puts food on the table. I try to improve C++ as much as possible, knowing that it is an imperfect language. Sure, I use C++ too. I really only know about Rust from a distance, I'm not a Rust programmer. C++ still has considerable advantages: excellent first-class support on all major platforms, a wealth of libraries available, mature tooling (static analysis, dynamic analysis, top-notch IDEs). Of course, some major software frameworks are natively C++, so you're strongly encouraged to stick with C++ (Qt, Direct3D). > C++ is heading into safe direction, and I'm sure C++26 will be able to provide more features to write code safely. The C-style footguns will probably still be there in 20 years. Yes, they've given us std::vector and std::array which allow us to manage arrays more safely than raw C arrays, but read-before-write is still undefined behaviour, dereferencing null is still undefined behaviour, divide-by-zero is still undefined behaviour. They gladly add more functionality to the standard library, but they're very reluctant to tweak the core of the language. At least we have two's complement guaranteed by the C++ standard now. > Rust seriously need to add Function Overloading, Generics. I wasn't aware Rust lacked generics. That sounds frustrating. I have mixed feelings on function overloading. It makes it harder to reason about what function is being called. [0] https://doc.rust-lang.org/reference/behavior-not-considered-unsafe.html https://doc.rust-lang.org/reference/behavior-not-considered-... [1] https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/Math.html#addExact(int,int) https://docs.oracle.com/en/java/javase/16/docs/api/java.base...
- v8dev123 5y ago
  > read-before-write is still undefined behaviour, dereferencing null is still undefined behaviour, divide-by-zero You rarely do these in Modern C++. It's your responsibility to check the input of program before doing anything with it. Structured Exception Handling aka SEH Exceptions can catch things like divide-by-zero, read-before-write, dereferencing null > The C-style footguns will probably still be there in 20 years. It's your job to know these footguns. Actually, it will take 2-3 months for a new programmer to separate C++ and C and understand what Modern C++ actually about. > I have mixed feelings on function overloading. It makes it harder to reason about what function is being called. It doesn't because overloading depends on the arguments not on the function names Without overloading, things become ugly.
  - MaxBarraclough 5y ago
    > You rarely do these in Modern C++. As I said before, one way or another, undefined behaviour is still a major problem in C++ codebases. This isn't really up for debate. pjmlp provided a good link on this. Most of Chromium's serious security bugs are due to memory safety issues. [0] > It's your responsibility to check the input of program before doing anything with it. C++ makes it the programmer's responsibility to avoid undefined behaviour. Programmers are not capable of doing this reliably. We're now at the point that it's no longer credible to argue otherwise. Even after all these decades it's still a problem for C++. > Structured Exception Handling aka SEH Exceptions can catch things like divide-by-zero, read-before-write, dereferencing null Sure, and with GCC/Clang, there are equivalent flags to enable trap-on-error for these errors. They're rarely used in production though, so we still face the consequences of undefined behaviour. > It's your job to know these footguns. Again, we've seen that C and C++ programmers simply are not capable of avoiding undefined behaviour. Even Google is unable to keep UB out of their prized Chromium codebase, despite their considerable investment. > It doesn't because overloading depends on the arguments not on the function names That's the definition of overloading, not a refutation of my point. In a language like C with no overloading, the function identifier is enough to uniquely identify the function. You don't need to check if there are overloads, the identifier is enough. If you introduce overloading, that property no longer holds. You might work under the mistaken impression there are no other overloads of a function, or it might be non-trivial to determine the types being passed, especially in the presence of type-inference. It's resolved at compile time, rather than at runtime, but my point stands. > Without overloading, things become ugly. It's a tradeoff. [0] https://news.ycombinator.com/item?id=26862330 https://news.ycombinator.com/item?id=26862330

MaxBarraclough 5y ago

> I can't use an informal reference to reason about its actual behavior. I don't follow here. You can do that. There's a more formal reference too though. [0] > Relying on integer overflow’s wrapping behavior is considered an error Good point, I'd missed that. So, Rust strongly discourages relying on the wrapping behaviour of release builds. It seems to take the opposite approach that Java uses. In Java, you get wrapping arithmetic 'by default' (i.e. when using the arithmetic operators), and there are special functions that give throw-on-overflow behaviour (which almost no one uses). [1] In Rust, the arithmetic operators handle overflow either by wrapping or by panic, depending on build configuration, and if you deliberately want to overflow, there are special functions for that (i32::wrapping_add) which behave identically on Debug and Release builds. I believe Ada does something similar. > At the end of the day, C++ puts food on the table. I try to improve C++ as much as possible, knowing that it is an imperfect language. Sure, I use C++ too. I really only know about Rust from a distance, I'm not a Rust programmer. C++ still has considerable advantages: excellent first-class support on all major platforms, a wealth of libraries available, mature tooling (static analysis, dynamic analysis, top-notch IDEs). Of course, some major software frameworks are natively C++, so you're strongly encouraged to stick with C++ (Qt, Direct3D). > C++ is heading into safe direction, and I'm sure C++26 will be able to provide more features to write code safely. The C-style footguns will probably still be there in 20 years. Yes, they've given us std::vector and std::array which allow us to manage arrays more safely than raw C arrays, but read-before-write is still undefined behaviour, dereferencing null is still undefined behaviour, divide-by-zero is still undefined behaviour. They gladly add more functionality to the standard library, but they're very reluctant to tweak the core of the language. At least we have two's complement guaranteed by the C++ standard now. > Rust seriously need to add Function Overloading, Generics. I wasn't aware Rust lacked generics. That sounds frustrating. I have mixed feelings on function overloading. It makes it harder to reason about what function is being called. [0] https://doc.rust-lang.org/reference/behavior-not-considered-unsafe.html https://doc.rust-lang.org/reference/behavior-not-considered-... [1] https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/Math.html#addExact(int,int) https://docs.oracle.com/en/java/javase/16/docs/api/java.base...

v8dev123 5y ago
> read-before-write is still undefined behaviour, dereferencing null is still undefined behaviour, divide-by-zero You rarely do these in Modern C++. It's your responsibility to check the input of program before doing anything with it. Structured Exception Handling aka SEH Exceptions can catch things like divide-by-zero, read-before-write, dereferencing null > The C-style footguns will probably still be there in 20 years. It's your job to know these footguns. Actually, it will take 2-3 months for a new programmer to separate C++ and C and understand what Modern C++ actually about. > I have mixed feelings on function overloading. It makes it harder to reason about what function is being called. It doesn't because overloading depends on the arguments not on the function names Without overloading, things become ugly.
- MaxBarraclough 5y ago
  > You rarely do these in Modern C++. As I said before, one way or another, undefined behaviour is still a major problem in C++ codebases. This isn't really up for debate. pjmlp provided a good link on this. Most of Chromium's serious security bugs are due to memory safety issues. [0] > It's your responsibility to check the input of program before doing anything with it. C++ makes it the programmer's responsibility to avoid undefined behaviour. Programmers are not capable of doing this reliably. We're now at the point that it's no longer credible to argue otherwise. Even after all these decades it's still a problem for C++. > Structured Exception Handling aka SEH Exceptions can catch things like divide-by-zero, read-before-write, dereferencing null Sure, and with GCC/Clang, there are equivalent flags to enable trap-on-error for these errors. They're rarely used in production though, so we still face the consequences of undefined behaviour. > It's your job to know these footguns. Again, we've seen that C and C++ programmers simply are not capable of avoiding undefined behaviour. Even Google is unable to keep UB out of their prized Chromium codebase, despite their considerable investment. > It doesn't because overloading depends on the arguments not on the function names That's the definition of overloading, not a refutation of my point. In a language like C with no overloading, the function identifier is enough to uniquely identify the function. You don't need to check if there are overloads, the identifier is enough. If you introduce overloading, that property no longer holds. You might work under the mistaken impression there are no other overloads of a function, or it might be non-trivial to determine the types being passed, especially in the presence of type-inference. It's resolved at compile time, rather than at runtime, but my point stands. > Without overloading, things become ugly. It's a tradeoff. [0] https://news.ycombinator.com/item?id=26862330 https://news.ycombinator.com/item?id=26862330