3 ms·

In every other language (except C), basically every time you write v[x]=y you aren't inviting the possibility of arbitary memory corruption. The C++ 'std::optio

In every other language (except C), basically every time you write v[x]=y you aren't inviting the possibility of arbitary memory corruption. The C++ 'std::optional' type makes calling '*v' undefined behaviour if 'v' is empty. The whole point of optional is to store things that might be empty, so why put undefined behaviour on the most common operation on an optional when it's empty (which is going to be common in practice, that's the point!) The problem I have with C++ (and I've written a lot), is every programmer involved in your project has to be 100% perfect, 100% of the time. I know you can run memory checkers, and STL debug modes, but unless you are running these in release as well (is anyone doing that?), then you are then counting on your testsuite hitting every weird thing a silly, or malicious, user might do. Given how important software is nowadays, and how Rust seems close to the performance of C++, is it really worth using a language where so many of the basic fundamental features are incredibly hard to use safely? They keep making it worse, calling an empty std::function threw an assert, the new std::copyable_function has made this undefined behaviour instead!

CyberDildonics 2y ago
The C++ 'std::optional' type makes calling 'v' undefined behaviour if 'v' is empty* Are you talking about dereferencing a null pointer? That is going to case a low level exception in any language, it has nothing to do with std::optional. every time you write v[x]=y you aren't inviting the possibility of arbitary memory corruption That's how computers work. You either pay the penalty of turning every memory check into a conditional boundary check first or you avoid it all together and just iterate through data structures, which is not difficult to do. Also debug mode lets you turn on the bounds checking to debug and be fast in release mode. The reality is that with a tiny amount of experience this is almost never a problem. Things like this are mostly relegated to writing your own data structures.
- CJefferson 2y ago
  No, I'm talking about std::optional<T>. It's a type designed to store an object of type T, or nothing. You use '*v' to get the value out (if one is present). It was originally discussed as a way of avoid null pointers, for the common case where they are representing the possibility of having a value. However, it has exactly the same UB problems as a null pointer, so isn't really any safer. I'm going to be honest, saying that memory corruption in C++ is 'almost never a problem' just doesn't match with my experience, of working on many large codebases, games, and seeing remote security holes caused by buffer overflows and memory corruption occurring in every OS and large software program ever written. Also, that 'penalty' really does seem to be tiny, as far as I can tell. Rust pays it (you can use unsafe to disable it, but most programs use unsafe very sparingly), and as far as I've seen benchmarks, the introduced overhead is tiny, a couple of percent at most.
  - CyberDildonics 2y ago
    It was originally discussed as a way of avoid null pointers, I don't think this is true. I don't think it has anything to do with null pointers, it is a standard way to return a type that might not be constructed/valid. I think you might be confusing the fact that you can convert std::optional to a bool and do if(opt){ opt.value(); } You might also be confusing it for the technique of passing an address into a function that takes a pointer as an argument, where the function can check the pointer for being null before it puts a value into the pointer's address. I'm going to be honest, saying that memory corruption in C++ is 'almost never a problem' just doesn't match with my experience, In modern C++ it is easy to avoid putting yourself in situations where you are calculating arbitrary indices outside of data structures. Whether people do this is another story. It would (or should) crash your program in any other language anyway. Also, that 'penalty' really does seem to be tiny The penalty is not tiny unless it is elided all together, which would happen in the same iteration scenarios that in C++ wouldn't be doing raw indexes anyway.
    - Maxatar 2y ago
      >I don't think this is true. I don't think it has anything to do with null pointers The paper that proposed std::optional literally uses examples involving null pointers as one of the use cases that std::optional is intended to replace: https://isocpp.org/files/papers/N3672.html https://isocpp.org/files/papers/N3672.html Here is an updated paper which is intended to fix some flaws with std::optional and literally mentions additional use cases of nullptr that the original proposal did not address but the extended proposal does: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2988r0.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p29... I am going to be somewhat blunt, but if you're not familiar with how some of the use cases for std::optional is as a replacement for using raw pointers, along with some of your comments about how C++ treats undefined behavior, as if it's just results in an exception, suggests you may not have a rigorous enough understanding of the language to speak so assertively about the topic.
      - CyberDildonics 2y ago
        I am going to be somewhat blunt, but if you're not familiar with how some of the use cases for std::optional is as a replacement for using raw pointers I never said there wasn't a use case, I said it wasn't specifically about protecting you from them. If you put a null pointer in and reference the value directly, it doesn't save you. If you don't understand the context of the thread start arguments over other people's simplified examples. I'm not going to write huge paragraphs to try to avoid someone's off topic criticisms, I'm just telling someone their problems can be avoided.

CyberDildonics 2y ago

The C++ 'std::optional' type makes calling 'v' undefined behaviour if 'v' is empty* Are you talking about dereferencing a null pointer? That is going to case a low level exception in any language, it has nothing to do with std::optional. every time you write v[x]=y you aren't inviting the possibility of arbitary memory corruption That's how computers work. You either pay the penalty of turning every memory check into a conditional boundary check first or you avoid it all together and just iterate through data structures, which is not difficult to do. Also debug mode lets you turn on the bounds checking to debug and be fast in release mode. The reality is that with a tiny amount of experience this is almost never a problem. Things like this are mostly relegated to writing your own data structures.

CJefferson 2y ago
No, I'm talking about std::optional<T>. It's a type designed to store an object of type T, or nothing. You use '*v' to get the value out (if one is present). It was originally discussed as a way of avoid null pointers, for the common case where they are representing the possibility of having a value. However, it has exactly the same UB problems as a null pointer, so isn't really any safer. I'm going to be honest, saying that memory corruption in C++ is 'almost never a problem' just doesn't match with my experience, of working on many large codebases, games, and seeing remote security holes caused by buffer overflows and memory corruption occurring in every OS and large software program ever written. Also, that 'penalty' really does seem to be tiny, as far as I can tell. Rust pays it (you can use unsafe to disable it, but most programs use unsafe very sparingly), and as far as I've seen benchmarks, the introduced overhead is tiny, a couple of percent at most.
- CyberDildonics 2y ago
  It was originally discussed as a way of avoid null pointers, I don't think this is true. I don't think it has anything to do with null pointers, it is a standard way to return a type that might not be constructed/valid. I think you might be confusing the fact that you can convert std::optional to a bool and do if(opt){ opt.value(); } You might also be confusing it for the technique of passing an address into a function that takes a pointer as an argument, where the function can check the pointer for being null before it puts a value into the pointer's address. I'm going to be honest, saying that memory corruption in C++ is 'almost never a problem' just doesn't match with my experience, In modern C++ it is easy to avoid putting yourself in situations where you are calculating arbitrary indices outside of data structures. Whether people do this is another story. It would (or should) crash your program in any other language anyway. Also, that 'penalty' really does seem to be tiny The penalty is not tiny unless it is elided all together, which would happen in the same iteration scenarios that in C++ wouldn't be doing raw indexes anyway.
  - Maxatar 2y ago
    >I don't think this is true. I don't think it has anything to do with null pointers The paper that proposed std::optional literally uses examples involving null pointers as one of the use cases that std::optional is intended to replace: https://isocpp.org/files/papers/N3672.html https://isocpp.org/files/papers/N3672.html Here is an updated paper which is intended to fix some flaws with std::optional and literally mentions additional use cases of nullptr that the original proposal did not address but the extended proposal does: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2988r0.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p29... I am going to be somewhat blunt, but if you're not familiar with how some of the use cases for std::optional is as a replacement for using raw pointers, along with some of your comments about how C++ treats undefined behavior, as if it's just results in an exception, suggests you may not have a rigorous enough understanding of the language to speak so assertively about the topic.
    - CyberDildonics 2y ago
      I am going to be somewhat blunt, but if you're not familiar with how some of the use cases for std::optional is as a replacement for using raw pointers I never said there wasn't a use case, I said it wasn't specifically about protecting you from them. If you put a null pointer in and reference the value directly, it doesn't save you. If you don't understand the context of the thread start arguments over other people's simplified examples. I'm not going to write huge paragraphs to try to avoid someone's off topic criticisms, I'm just telling someone their problems can be avoided.