Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust for C++ programmers – part 4: unique pointers

featherweightmusings.blogspot.com

Post reply on HN
Print view View original

21–30 of 99 posts

Re: Rust for C++ programmers – part 4: unique pointers

#21

Post by captainmuon »

Rust gives me the same feeling I had when learning C. I started with BASIC, then learned Java and a bit of Pascal, Perl, etc., but C was my first language with pointers. Now it seems silly, but understanding pointers was a huge step to me. There's a before and an after. Getting used to owned/transferable pointers seems to involve a similar step, although it's probably easier this time since I understand what they do.

Btw., if you like this kind of intelligent pointers, Vala something similar [1], and the syntax seems a bit easier at first glance. You have owned pointers (and can transfer ownership), shared pointers (with reference counting) and unmanaged pointers. It uses reference counting for all the UI stuff (Vala is highly integrated with Glib and Gtk), since that is usually not performance critical and you'd rather be correct there. If you feel the need to do without reference counting, you can manage memory manually, too.

[1]: https://wiki.gnome.org/Projects/Vala/ReferenceHandling

Re: Rust for C++ programmers – part 4: unique pointers

#22

Post by masklinn »

frozenport wrote: post #15
rcthompson wrote: post #7

Earlier quoted context omitted.

If the pointer is returned all the way up to the main function, then it must be required for the lifetime of the program (or else the program is poorly designed). What point are you trying to make?

It could also be a memory leak. For example, I have a for loop that keeps requesting a new pointer...

> For example, I have a for loop that keeps requesting a new pointer...

Unless you put that pointer in a structure which lives forever, it will be freed as soon as a loop finishes:

    struct Foo { a: int, b: int }
    impl Drop for Foo {
        fn drop(&mut self) {
            println!("Drop {:?}", *self);
        }
    }

    fn foo(i: int) -> Foo {
        println!("Creating Foo with {}", i);
        Foo { a: i, b: 5}
    }

    fn do_thing(foo: &Foo) {
        println!("\tdo thing {:?}", *foo);
    }
    fn do_other_thing(foo: &Foo) {
        println!("\tdo other thing {:?}", *foo);
    }

    fn main() {
        for i in range(0, 5) {
            let a = box foo(i);
            do_thing(a);
            do_other_thing(a);
        }
    }
will print

    Creating Foo with 0
        do thing Foo{a: 0, b: 5}
        do other thing Foo{a: 0, b: 5}
    Drop Foo{a: 0, b: 5}
    Creating Foo with 1
        do thing Foo{a: 1, b: 5}
        do other thing Foo{a: 1, b: 5}
    Drop Foo{a: 1, b: 5}
    Creating Foo with 2
        do thing Foo{a: 2, b: 5}
        do other thing Foo{a: 2, b: 5}
    Drop Foo{a: 2, b: 5}
    Creating Foo with 3
        do thing Foo{a: 3, b: 5}
        do other thing Foo{a: 3, b: 5}
    Drop Foo{a: 3, b: 5}
    Creating Foo with 4
        do thing Foo{a: 4, b: 5}
        do other thing Foo{a: 4, b: 5}
    Drop Foo{a: 4, b: 5}
(drop is ~equivalent to a C++ destructor)

Re: Rust for C++ programmers – part 4: unique pointers

#23

Post by AlisdairO »

frozenport wrote: post #15
rcthompson wrote: post #7

Earlier quoted context omitted.

If the pointer is returned all the way up to the main function, then it must be required for the lifetime of the program (or else the program is poorly designed). What point are you trying to make?

It could also be a memory leak. For example, I have a for loop that keeps requesting a new pointer...

I just tried the following:

        let mut blah = ~MyStruct{x: 3, y: 4};
        for i in range(0,100000000) {
            blah = ~MyStruct{x: i + blah.x, y: i + blah.y};
        }
        println!("{} {}", blah.x, blah.y);
The memory usage didn't increase over time - the owned pointer frees when it gets reassigned.

Re: Rust for C++ programmers – part 4: unique pointers

#24

Post by seertaak »

pcwalton wrote: post #5
rdtsc wrote: post #4

Rust looks very exciting and promising. I see the hardest things for it to be not necessarily syntax and concurrency (which are very well done), but performance and getting to compete with C++11 (C++14), which actually seems to become fresh and interesting again. Performance is tough. I feel most often C++ is not chosen for its inherent cleanliness, elegance and beauty, but because there are no viable competitors at…

I feel pretty good about it. For one, we have significantly better aliasing information than C++, and we use most of the guts, including all the optimizations and code generation, of a C++ compiler (clang/LLVM). There are also some optimizations around move semantics that are open to us but not for C++ as standardized. That said, there are definitely performance bugs that have yet to be fixed. But I would definitely…

> There are also some optimizations around move semantics

That piqued my curiosity -- would you mind going into a little more detail, or point me to somewhere where these are discussed?

Re: Rust for C++ programmers – part 4: unique pointers

#25

Post by berkut »

pcwalton wrote: post #5
rdtsc wrote: post #4

Rust looks very exciting and promising. I see the hardest things for it to be not necessarily syntax and concurrency (which are very well done), but performance and getting to compete with C++11 (C++14), which actually seems to become fresh and interesting again. Performance is tough. I feel most often C++ is not chosen for its inherent cleanliness, elegance and beauty, but because there are no viable competitors at…

I feel pretty good about it. For one, we have significantly better aliasing information than C++, and we use most of the guts, including all the optimizations and code generation, of a C++ compiler (clang/LLVM). There are also some optimizations around move semantics that are open to us but not for C++ as standardized. That said, there are definitely performance bugs that have yet to be fixed. But I would definitely…

How does one do intrinsics (SSE / AVX) in Rust - I guess they're just the exposed functions from emmintrin.h and the compiler calls them directly?

How do you do ASM in Rust?

Can you align memory in rust?

Re: Rust for C++ programmers – part 4: unique pointers

#26

Post by mercurial »

jcmoyer wrote: post #10
bambam12897 wrote: post #8

I've been working C++ professionally for a couple of years and honestly I'm a huge fan - So I was excited to read about an alternative. After reading your 5 posts, I get the impression that RUST is mostly mildly useful syntactic sugar on top of C++. Here is my feedback: 1 - If memory management is a serious problem for the software you work on, I've never found the boost library lacking. This seems like the main sell…

>1 - If memory management is a serious problem for the software you work on, I've never found the boost library lacking. This seems like the main selling point for RUST. Given the scope of the project: you guys must be doing something that is so different that it couldn't be rolled into a library - so I'm looking forward to your future posts to see if there is something here that I really am missing out on. I would s…

I'll add that Rust's match statement, as far as I can see, is more powerful than what Haskell offers: it combines pattern matching and guards, and lets you match different pattern with the same block (the patterns should bind the same variables and they should have the same type, obviously).

Re: Rust for C++ programmers – part 4: unique pointers

#28

Post by ahy1 »

comex wrote: post #13
bambam12897 wrote: post #8

I've been working C++ professionally for a couple of years and honestly I'm a huge fan - So I was excited to read about an alternative. After reading your 5 posts, I get the impression that RUST is mostly mildly useful syntactic sugar on top of C++. Here is my feedback: 1 - If memory management is a serious problem for the software you work on, I've never found the boost library lacking. This seems like the main sell…

> 1 - If memory management is a serious problem for the software you work on, I've never found the boost library lacking. A key feature of Rust is being memory safe by default without sacrificing too much performance. In C++ it's not really possible to be completely safe, and pretty much all real-world C++ I've seen doesn't even come close to that ideal, using raw pointers frequently; the result is that crashes can b…

> Most C++ code uses switch frequently, usually without taking advantage of fallthrough.

I am not so sure about this. Thinking back on my uses of switch in C and C++, I am not able to remember using switch without taking advantage of fallthrough. Maybe I am just not a typical C++ programmer...

Re: Rust for C++ programmers – part 4: unique pointers

#30

Post by alkonaut »

kirab wrote: post #27

What the heck is this? y: ~~~~~Foo

y is a pointer to a pointer to a pointer to a pointer to a pointer to an instance of Foo.

What the author wanted to show was that there is automatic dereference:

z = y.foo()

Will just reference through all five pointers and call the method on the object directly.

Post reply on HN