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

61–70 of 99 posts

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

#61

Post by pcwalton »

captainmuon wrote: post #21

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.…

> 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.

That doesn't sound safe—what if unowned pointers outlive the owned pointer, and you get use-after-free?

I don't believe it's possible to avoid pervasive reference counting or GC in a practical sense, and still be safe, without something like lifetimes built into the type system.

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

#62

Post by pcwalton »

nly wrote: post #54
bad_user wrote: post #36

Earlier quoted context omitted.

> If memory management is a serious problem for the software you work on, I've never found the boost library lacking. As a developer that isn't working with C++, I'm finding memory management in C++ to be a nightmare and no amount of libraries can solve it. Say you receive a pointer from somewhere. Is the referenced value allocated on the stack or on the heap? If allocated on the heap, do you need to free it yourself…

> Say you receive a pointer from somewhere. Here's your problem. In general I don't want to be receiving a single pointer from anyone. Lately, I've found it helpful to think of pointers in C++ as special iterators rather than a referential relic from C. In such a mindset passing pointers around without an accompanying end iterator, or iteration count, just makes no sense. Anywhere that implied iteration count is alwa…

> In such a mindset passing pointers around without an accompanying end iterator, or iteration count, just makes no sense. Anywhere that implied iteration count is always a constant, I'm probably not structuring my code correctly.

Passing around two iterators is still not safe, due to iterator invalidation.

Memory safety in the C++ model is a hard problem.

> So my recommendation is to use references (foo&) for passing down (well, up) the stack, never to heap allocated objects.

I don't think this is practical. Consider `operator[]` on a vector, which returns a reference to a heap allocated object. If that were to copy out, you'd have a lot of overhead, and if it were to move, then a lot of very common patterns would be annoying to write.

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

#63

Post by pcwalton »

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.

When use-after-free becomes a security concern that commonly leads to remote code execution, as it is for us in the browser space, it becomes very apparent just how inadequate modern C++ is at the task. Everything works fine, the tests pass, people use it in production, and yet all the time someone discovers some way to make the stars align to produce a use-after-free bug. This has happened over and over again, despite all the smart pointers and modern C++ techniques.

The fact is that modern C++ just isn't memory safe, and after digging deep into the problem to try to solve it with Rust I'm convinced now that it can never be. The language just has too many core features, such as references, iterators, and the "this" pointer, that cannot be made memory safe without sacrificing backwards compatibility.

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

#64

Post by kam »

Pxtl wrote: post #59
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…

Nobody will ever beat C/C++ for raw soft-real-time speed. Even a language like Rust that may have the linguistic features to be blazingly fast will never close that massive gap in historical optimization. Rust will never have an Intel-compiler. That said, Rust will get close to C/C++ in ways that GC-based languages never will. GC languages mean memory bloat and soft-realtime problems related to GC cleaning. It will l…

> Rust will never have an Intel-compiler.

Yesterday, Intel announced a project combining a clang frontend with icc's backend. [1] The backend takes LLVM IR, so hopefully Rust's LLVM IR output could be run through it.

[1] https://news.ycombinator.com/item?id=7663462

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

#65

Post by loup-vaillant »

Pxtl wrote: post #59
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…

Nobody will ever beat C/C++ for raw soft-real-time speed. Even a language like Rust that may have the linguistic features to be blazingly fast will never close that massive gap in historical optimization. Rust will never have an Intel-compiler. That said, Rust will get close to C/C++ in ways that GC-based languages never will. GC languages mean memory bloat and soft-realtime problems related to GC cleaning. It will l…

> Even a language like Rust that may have the linguistic features to be blazingly fast will never close that massive gap in historical optimization. Rust will never have an Intel-compiler.

That's most probably false: the current self-hosting implementation have an LLVM backend. So it has back end optimisations covered. As for the front end, Rust's cleaner semantics will make many optimizations easier.

Plus, it's not like the historical gap couldn't be closed by reading the gazillion papers on C++ optimization out there. Copying a known technique is much faster than developing it in the first place.

Maybe Rust will end up slower than C++ anyway, but it won't be the compiler's fault.

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

#66

Post by loup-vaillant »

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 most often C++ is not chosen for its inherent cleanliness, elegance and beauty, but because there are no viable competitors at the given performance point.

My feeling is that most often, (i) people don't need nearly as much performance as they think, and (ii) they greatly overestimate the performance gap between C++ and garbage collected languages (most notably those who are compiled to native code, such as Lisp, ML, and Haskell).

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

#67

Post by pohl »

loup-vaillant wrote: post #66
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 most often C++ is not chosen for its inherent cleanliness, elegance and beauty, but because there are no viable competitors at the given performance point. My feeling is that most often, (i) people don't need nearly as much performance as they think, and (ii) they greatly overestimate the performance gap between C++ and garbage collected languages (most notably those who are compiled to native code, such as…

they greatly overestimate the performance gap between C++ and garbage collected languages

I think you're right about that, but I also think that people greatly underestimate the determinism gap between them, too. (Not necessarily the same set of people, of course.)

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

#68

Post by loup-vaillant »

masklinn wrote: post #20
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…

> 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 Memory safety and static checking. > A lot of things are renamed. auto->let, new->box, switch->box You get the feeling that effort was put in to make the language explicitly look different from C++ * let comes from ML and similar languages (e.g. Haskell), which are a huge inspiration of Ru…

If I had to guess, I'd say "box" is a reference to "boxed values" mentioned in many papers about functional language compilation. Typically, the stack of these implementation would either be "unboxed values", or pointers to "boxes" on the heap.

Clearly, some of those folks have worked on ML or Haskell implementations.

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

#69

Post by loup-vaillant »

pohl wrote: post #67
loup-vaillant wrote: post #66

Earlier quoted context omitted.

> I feel most often C++ is not chosen for its inherent cleanliness, elegance and beauty, but because there are no viable competitors at the given performance point. My feeling is that most often, (i) people don't need nearly as much performance as they think, and (ii) they greatly overestimate the performance gap between C++ and garbage collected languages (most notably those who are compiled to native code, such as…

they greatly overestimate the performance gap between C++ and garbage collected languages I think you're right about that, but I also think that people greatly underestimate the determinism gap between them, too. (Not necessarily the same set of people, of course.)

I'm not sure. If you start using smart pointers in C++, you can get the same problem: instead of a GC pause, you get a cascading delete pause. To eliminate it, you have to devise a smarter memory scheme, at which point you probably don't underestimate the determinism cap.

Also don't forget that garbage collectors can often be tuned. Granted, many of them suck, but a generational, incremental collector whose parameters can be tweaked? Much less room for pauses.

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

#70

Post by loup-vaillant »

bad_user wrote: post #36
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…

> If memory management is a serious problem for the software you work on, I've never found the boost library lacking. As a developer that isn't working with C++, I'm finding memory management in C++ to be a nightmare and no amount of libraries can solve it. Say you receive a pointer from somewhere. Is the referenced value allocated on the stack or on the heap? If allocated on the heap, do you need to free it yourself…

> if a C++ project doesn't have multiple conflicting ways of dealing with memory management and multiple String classes, then it's not mature enough.

Hmm… How can I tell maturity from rot?

Post reply on HN