Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Freed memory issues can be avoided using std::unique_ptr and its siblings

You can use a std::unique_ptr after it is assigned to something else. That's basically a use after free.

> lost pointers to local variables shouldn’t occur when using references instead of pointers

Lost references to heap variables happen all the time in C++ when the target is deallocated before the reference is accessed. It's the same problem and Rust fixes it the same way.

> I don’t get the problems with "A dangerous switch" and "A broken semicolons", both seem sensible constructs

Really? Then you're being naïve or obtuse. Both are common sources of bugs in C/C++. Accidental failure to handle all inputs (common when additional inputs are added after the handling code is written) and subtle typos with major consequences (see Apple's "goto fail" bug).

The purpose of Rust is to eliminate causes of careless and accidental errors by forcing you to do things the right way every time (rather than permitting lazy code).



Good reply; would be better without that small sentence after "really?", though :)


> You can use a std::unique_ptr after it is assigned to something else. That's basically a use after free.

While true, you can make it throw in such scenarios.

I wouldn't be surprised if the debug builds of modern C++ compilers wouldn't do it already.


Here is some example code showing the problem:

http://pastebin.com/6wu7bcrF

I compiled it using both:

  g++     -std=c++14 -Wall -Wextra -g test.cpp -o test
  clang++ -std=c++14 -Wall -Wextra -g test.cpp -o test
GCC v4.9.1 and Clang v3.5.0.

Under neither case did it supply any warnings at compile time. In both cases it segfaults when it hits the second std::cout whilst running.


Since that's undefined behavior anything (including and especially things worse than a segmentation fault) could happen.


-Weverything on clang is what you want


That's a useful option to know, thanks. However, it still didn't detect the problem being discussed.


Still, those are just two among many.


> Really? Then you're being naïve or obtuse. Both are common sources of bugs in C/C++. Accidental failure to handle all inputs (common when additional inputs are added after the handling code is written) and subtle typos with major consequences (see Apple's "goto fail" bug).

I don’t know, it seems reasonable to me to allow switch() not to handle all possible inputs and/or fall through. Requiring for() loops to always have a body also seems unnecessary, there are cases where everything fits nicely into the three standard elements.


Rust allows you to not handle all possible inputs (but you must be explicit about it). If you look at the page again, you'll see "_ => 3", which is the rust version of a default case. This means that rust can tell if you if you forgot to handle a certain case.

As for the other things you list, I'd mark these more as "short-cuts", than features. It may take more effort to create code without them, but it gives parsing and code-readability improvements. Obviously the rust devs have made their decision here.


> You can use a std::unique_ptr after it is assigned to something else. That's basically a use after free.

No, that's a null pointer dereference.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: