Earlier quoted context omitted.
> In modern C++ we are (hopefully) using smart pointers (std::unique_ptr, std::shared_ptr) to manage heap-allocated object lifetimes. Those aren't safe. There are many ways to cause use-after-free with unique_ptr: for example, placing a uniquely-owned object in a vector and clearing the vector in a method call on that object.
True, and hopefully the likes of D, Rust and Go will improve the situation. In the mean time, we can take advantage of modern C++ safe constructs instead of keep on using C, as new language adoption always takes time.
A 30 minute introduction to Rust
61–70 of 161 posts
Re: A 30 minute introduction to Rust
#62Re: A 30 minute introduction to Rust
#63Re: A 30 minute introduction to Rust
#64I like this tutorial because dives straight into the most unique/unfamiliar parts of Rust (ownership/references) and gets them out of the way. It's a "learn the hard way"-style tutorial, and I think that's the best approach. Once you learn how ownership and borrowing work, along with ARCs and concurrency, everything else is really simple and just naturally falls out.
Re: A 30 minute introduction to Rust
#65Thanks for this. I've been thinking about getting into Rust recently and this motivates me to do so now.
Re: A 30 minute introduction to Rust
#66I'm a big fan of that kudos button! Very nice website and an interesting introduction to Rust.
Re: A 30 minute introduction to Rust
#67This isn't so much an introduction to Rust as it is an introduction to Rust's concurrency model. The example of returning a reference to an automatic variable isn't super compelling, since every competent C/C++ programmer knows not to do it. That bug does pop up every once in awhile, but almost always in the context of a function that returns a reference to one of many different possible variables depending on some c…
Salespeople qualify leads by determining if you're ready to buy or not. If you're not, they stop wasting time on you. The general idea for a quick introduction is to qualify your lead. So this isn't a "introduction to Rust's syntax" it's "an introduction to why you should (or should not) care about Rust." > since every competent C/C++ programmer knows not to do it. Everyone knows, yet programs still segfault. The poi…
Re: A 30 minute introduction to Rust
#68Earlier quoted context omitted.
Oh, don't get me wrong, I'm sold on memory protection as a type system feature. I'm just suggesting that the example you're using might make it sound less valuable, because returning stack variable references isn't the most common kind of error made by C programmers; when you do that, more often than not your program doesn't work at all.
Absolutely, I don't want people to think I'm attacking a straw man. Maybe a heap allocated example would be better?
#include
#include
void destroyer(int* val) {
printf("%d\n", *val);
free(val);
}
int main(int argc, char** argv) {
int* v = malloc(sizeof(int));
*v = 3;
destroyer(v);
printf("%d\n", *v);
return 0
}
Which compiles without warnings using Clang (unless -Weverything, and even then the warnings are not related to use-after-free), works "correctly" in O0 and O1 (prints "3" twice) then breaks starting at O2 (prints "3" then "0"). (note: it always prints "3" twice with GCC 4.8, showing how fun these things are)meanwhile the equivalent
fn main() {
let v = ~3;
destroyer(v);
println!("{}", *v)
}
fn destroyer(val: ~int) {
println!("{}", *val)
}
refuses to compile and explains why: test.rs:4:20: 4:21 error: use of moved value: `v`
test.rs:4 println!("{}", *v)
^
note: in expansion of format_args!
:224:8: 224:50 note: expansion site
:223:4: 225:6 note: in expansion of format!
:241:45: 241:63 note: expansion site
:240:4: 242:5 note: in expansion of println!
test.rs:4:4: 5:1 note: expansion site
test.rs:3:14: 3:15 note: `v` moved here because it has type `~int`, which is non-copyable (perhaps you meant to use clone()?)
test.rs:3 destroyer(v);
^
error: aborting due to previous error
which can be fixed either by explicitly cloning the value, or by altering the sub-function to not consider it owns the pointer (or by removing the `println!` call in `main()`, thus transferring the ownership of the pointer to the sub-function safely, of course)Re: A 30 minute introduction to Rust
#69Earlier quoted context omitted.
True, and hopefully the likes of D, Rust and Go will improve the situation. In the mean time, we can take advantage of modern C++ safe constructs instead of keep on using C, as new language adoption always takes time.
Go being mandatorily GC'd I don't think it's relevant to the issue of improving on C/C++ for their existing use cases.
Re: A 30 minute introduction to Rust
#70Earlier quoted context omitted.
> I'm just wondering if there are other magic pointer types or type system features that also protect memory. Oh, I see. In that case yes, there are also explicit lifetimes, which allow you to squeeze out more expressiveness to cover most of C++'s use cases for pointers/references: http://static.rust-lang.org/doc/master/guide-lifetimes.html There are no more magic pointer types, though; lifetimes are just annotations…
"Second, shared_ptr isn't very fast, due to some design decisions like ... not being intrusive (requiring 2x the allocations)." Not quite. You can use std::make_shared to allocate the object and the ref count in one allocation. You get improved locality of reference as an added bonus.