7 ms·
> 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 basica
by gilgoomesh 12y ago
> 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).
- claudius 12y ago> 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.
- keeperofdakeys 12y agoRust 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.
- icebraining 12y agoGood reply; would be better without that small sentence after "really?", though :)
- pjmlp 12y ago> 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.
- mike-cardwell 12y agoHere is some example code showing the problem: http://pastebin.com/6wu7bcrF 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.
- tomjakubowski 12y agoSince that's undefined behavior anything (including and especially things worse than a segmentation fault) could happen.
- deleted 12y ago[deleted]
- pjmlp 12y agoStill, those are just two among many.
- beached_whale 12y ago-Weverything on clang is what you want
- mike-cardwell 12y agoThat's a useful option to know, thanks. However, it still didn't detect the problem being discussed.
- SamReidHughes 12y ago> 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.