4 ms·

Is it though? I feel like most people compare Rust to C++98 and if you do that, certainly Rust looks really good. The benefits of Rust compared to, say, C++17 a

Is it though? I feel like most people compare Rust to C++98 and if you do that, certainly Rust looks really good. The benefits of Rust compared to, say, C++17 are not as pronounced.

FartyMcFarter 6y ago
It's still quite easy to shoot oneself in the foot with modern C++: #include <string_view> #include <string> #include <iostream> int main() { std::string_view v = std::string("xyz"); std::cout << v << '\n'; }
- rhodysurf 6y ago
  OK i'll bite. What's wrong with this? It functions as expected or am I missing something. Edit: NVM, for those wondering the std::string constructor copies the string when it doesnt have to. But the solution here is to just initialize the string_view with the char data instead of the std::string instance Edit: Ignore me see below
  - steveklabnik 6y ago
    Isn't it a use-after free? (I haven't had time to compile and run it) You have a temporary std::string, pointed to by a string_view, which means that it's freed, and the view is dangling, and then used when printing things out.
    - rhodysurf 6y ago
      So thats what I initially thought but then I ran it and it works so IDK anything anymore.
      - steveklabnik 6y ago
        UB can do anything, including something that seems like it works. Just because the memory has been deallocated doesn't mean that the bytes there were changed. The pointer may still point to them, and it may still "work."
      - mlindner 6y ago
        It's undefined behavior, so it'll literally print anything. On my system with my compiler version it'll print xyz without any optimization, but if I use -O3 optimization it prints nothing. But it could just as easily segfault or print garbage from memory. Edit: If I move the first line into a function and return that string_view, then with optimizations it still prints nothing, but without optimizations it prints random varying garbage each time I run it, different each time.
  - clappski 6y ago
    The issue isn’t anything to do with copying - the issue is that a string_view is a non-owning reference, and that std::string on the right side is an rvalue. Meaning that when you deref the char* in the string_view you’ll segfault or summon demons or something.
    - rhodysurf 6y ago
      Yeah I expected a segfault too... but it didnt happen for me and printed fine so I was confused.
      - Jtsummers 6y ago
        Try putting it inside another function and then return the string_view before printing. The behavior will be more interesting. The first time I got "V", then consistently "f" or "+" after that. A lot of C++'s (and C's) memory "fun" doesn't readily appear when you're inside a particular function because the memory (like here) is on the stack. So your behavior within that function scope looks like what you want. Then you start returning values and, oops, something was a reference to memory on the stack. In which case it more or may not work depending on what else has happened between the value being placed on the stack and its use (I had to run a fun crash course for EEs on stack vs heap, when your only programming experience is a bit of Matlab this is not a topic you'll be familiar with).
- dxuh 6y ago
  I'm try to not sound rude, but I don't think I can. Every C++ developer with even some significant amount of experience will identify this as bad code with one eye closed. Of course this looks wrong to someone that doesn't know the language. People freak out because it crashes your program, but in the end it's just a bug and producing bugs that are not obvious to someone that doesn't use the language much is very easy with every language. I remember people prophesizing the end of C++ because of the introduction of string_views. When writing a text editor over a couple of weeks (a lot of text manipulation) I used string_views extensively and purposely over-used them (returned them a lot or kept them for a long time), because I wanted to see how dangerous they could be and I never got a bug/crash that was related to them. Of course you have to think about what you are doing, but you should be doing that anyway. What I am trying to say is that while it's never "free" to not write bad code, if you get used to it, you don't have to think as hard about it, as you might think. There are way more common examples of easy ways to break your code, like storing references/pointers to elements in vectors, which then resize or capturing objects in lambdas that get destroyed before the lambda is executed and stuff like that. Even out-of-bounds access to arrays/vectors is a lot more common than that, I think personally.
  - mlindner 6y ago
    > People freak out because it crashes your program People freak out because it _doesn't_ crash your program (until it's running in production of course). On my system without optimizations it prints "xyz" just fine, with optimizations it prints nothing, even though I'm accessing to the middle of memory. I think on most systems this will not actually crash unless you have explicit out of bounds memory tracking inserted into code by the compiler every access slowing down your code. The point is in Rust this wouldn't even compile. I'd be curious if you ran your text editor through a memory sanitizer like valgrind and how many issues it points out.
    - pjmlp 6y ago
      In VC++ also not, as I do static analysis as part of the build.
adamnemecek 6y ago
Better cross platform, better build system, better packaging, simpler language, the list goes on.
- FartyMcFarter 6y ago
  > Better cross platform How many gaming consoles support rust?
  - adamnemecek 6y ago
    Same number as how many support LLVM.
  - steveklabnik 6y ago
    Rust code has successfully been compiled and ran on every one of the current generation of consoles, and many older consoles too. Now, many studios would want it to be directly supported by the console developers themselves, and that's obviously not a thing right now... but there's no technical limitations here.

Is it though? I feel like most people compare Rust to C++98 and if you do that, certainly Rust looks really good. The benefits of Rust compared to, say, C++17 are not as pronounced.

FartyMcFarter 6y ago

It's still quite easy to shoot oneself in the foot with modern C++: #include <string_view> #include <string> #include <iostream> int main() { std::string_view v = std::string("xyz"); std::cout << v << '\n'; }

rhodysurf 6y ago
OK i'll bite. What's wrong with this? It functions as expected or am I missing something. Edit: NVM, for those wondering the std::string constructor copies the string when it doesnt have to. But the solution here is to just initialize the string_view with the char data instead of the std::string instance Edit: Ignore me see below
- steveklabnik 6y ago
  Isn't it a use-after free? (I haven't had time to compile and run it) You have a temporary std::string, pointed to by a string_view, which means that it's freed, and the view is dangling, and then used when printing things out.
  - rhodysurf 6y ago
    So thats what I initially thought but then I ran it and it works so IDK anything anymore.
    - steveklabnik 6y ago
      UB can do anything, including something that seems like it works. Just because the memory has been deallocated doesn't mean that the bytes there were changed. The pointer may still point to them, and it may still "work."
    - mlindner 6y ago
      It's undefined behavior, so it'll literally print anything. On my system with my compiler version it'll print xyz without any optimization, but if I use -O3 optimization it prints nothing. But it could just as easily segfault or print garbage from memory. Edit: If I move the first line into a function and return that string_view, then with optimizations it still prints nothing, but without optimizations it prints random varying garbage each time I run it, different each time.
- clappski 6y ago
  The issue isn’t anything to do with copying - the issue is that a string_view is a non-owning reference, and that std::string on the right side is an rvalue. Meaning that when you deref the char* in the string_view you’ll segfault or summon demons or something.
  - rhodysurf 6y ago
    Yeah I expected a segfault too... but it didnt happen for me and printed fine so I was confused.
    - Jtsummers 6y ago
      Try putting it inside another function and then return the string_view before printing. The behavior will be more interesting. The first time I got "V", then consistently "f" or "+" after that. A lot of C++'s (and C's) memory "fun" doesn't readily appear when you're inside a particular function because the memory (like here) is on the stack. So your behavior within that function scope looks like what you want. Then you start returning values and, oops, something was a reference to memory on the stack. In which case it more or may not work depending on what else has happened between the value being placed on the stack and its use (I had to run a fun crash course for EEs on stack vs heap, when your only programming experience is a bit of Matlab this is not a topic you'll be familiar with).
dxuh 6y ago
I'm try to not sound rude, but I don't think I can. Every C++ developer with even some significant amount of experience will identify this as bad code with one eye closed. Of course this looks wrong to someone that doesn't know the language. People freak out because it crashes your program, but in the end it's just a bug and producing bugs that are not obvious to someone that doesn't use the language much is very easy with every language. I remember people prophesizing the end of C++ because of the introduction of string_views. When writing a text editor over a couple of weeks (a lot of text manipulation) I used string_views extensively and purposely over-used them (returned them a lot or kept them for a long time), because I wanted to see how dangerous they could be and I never got a bug/crash that was related to them. Of course you have to think about what you are doing, but you should be doing that anyway. What I am trying to say is that while it's never "free" to not write bad code, if you get used to it, you don't have to think as hard about it, as you might think. There are way more common examples of easy ways to break your code, like storing references/pointers to elements in vectors, which then resize or capturing objects in lambdas that get destroyed before the lambda is executed and stuff like that. Even out-of-bounds access to arrays/vectors is a lot more common than that, I think personally.
- mlindner 6y ago
  > People freak out because it crashes your program People freak out because it _doesn't_ crash your program (until it's running in production of course). On my system without optimizations it prints "xyz" just fine, with optimizations it prints nothing, even though I'm accessing to the middle of memory. I think on most systems this will not actually crash unless you have explicit out of bounds memory tracking inserted into code by the compiler every access slowing down your code. The point is in Rust this wouldn't even compile. I'd be curious if you ran your text editor through a memory sanitizer like valgrind and how many issues it points out.
  - pjmlp 6y ago
    In VC++ also not, as I do static analysis as part of the build.

adamnemecek 6y ago

Better cross platform, better build system, better packaging, simpler language, the list goes on.

FartyMcFarter 6y ago
> Better cross platform How many gaming consoles support rust?
- adamnemecek 6y ago
  Same number as how many support LLVM.
- steveklabnik 6y ago
  Rust code has successfully been compiled and ran on every one of the current generation of consoles, and many older consoles too. Now, many studios would want it to be directly supported by the console developers themselves, and that's obviously not a thing right now... but there's no technical limitations here.