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

Comparing Rust and C++

kukuruku.co

Post reply on HN
Print view View original

111–120 of 139 posts

Re: Comparing Rust and C++

#111

Post by shmerl »

iopq wrote: post #18
shmerl wrote: post #12

Earlier quoted context omitted.

What do you mean less common? Less commonly used or less commonly useful? Idiomatic C++11 discourages usage of raw pointers altogether. C++ introduced RAII ideas quite a long time ago, it's just in practice they weren't always followed and only in C++11 they were backed by standardized features from stdc++. Rust has an advantage of following this approach from the very beginning and not having all kind of legacy bagg…

Both, because you don't need them as often.

Not sure, I used them quite extensively in various projects and tried avoiding raw pointers. The only concern can be some cost of overhead when using them.

Re: Comparing Rust and C++

#112

Post by humanrebar »

Matthias247 wrote: post #91
humanrebar wrote: post #87

Earlier quoted context omitted.

I'm not aware of any production quality UI toolkits in Rust, but using traits and reference counting, Rust certainly supports this use case. In fact, it supports it more flexibly since different widgets don't have to share the same methods and data at all ... well, unless you want them to. And you can have your widgets implement more than one trait without having to combine them all into one giant class definition.

As soon as it supports storing trait objects in smart pointers and casting them. That's afaik still not the case.

You can as long as they are immutable objects. Again, you can't alias mutable references, even if they are of the exact same type.

Maybe you should read this: http://doc.rust-lang.org/guide.html#traits

Re: Comparing Rust and C++

#113

Post by humanrebar »

steveklabnik wrote: post #93
humanrebar wrote: post #89

Earlier quoted context omitted.

Off the top of my head: * C++ has more robust compile-time meta-programming facilities, at least for the time being. * C++ can generally include C (well, C89) code as-is with no translation layer. Rust's FFI is pretty inoffensive, but it's more work than a #include * It's easier to do the really dangerous stuff if you have a good reason to. You can actually call push_back on a std::vector without invalidating your it…

C++ can also easily bind to libraries written in C++, while Rust cannot. (those libraries need to expose a C interface for Rust to be able to)

That's true, though I blame C++ for its lack of a standard ABI more than I would blame Rust. Not that that helps if you're just trying to get work done.

Re: Comparing Rust and C++

#114

Post by steveklabnik »

humanrebar wrote: post #112
Matthias247 wrote: post #91

Earlier quoted context omitted.

As soon as it supports storing trait objects in smart pointers and casting them. That's afaik still not the case.

You can as long as they are immutable objects. Again, you can't alias mutable references, even if they are of the exact same type. Maybe you should read this: http://doc.rust-lang.org/guide.html#traits

I believe your parent is referring to storing trait objects in something like Arc, which is not supported: currently, Arc requires T to be sized.

Re: Comparing Rust and C++

#115

Post by pnathan »

claudius wrote: post #6

It might be a good idea to compare C++ and Rust and not “C with Classes and no use of compiler options” and Rust. They do have a fair point about ugly template error messages, but the remaining issues are mostly moot: Freed memory issues can be avoided using std::unique_ptr and its siblings, lost pointers to local variables shouldn’t occur when using references instead of pointers, uninitialised variables are warned…

> If there are new, delete or pointer arguments in functions in your code, you’re most likely doing it wrong.

Candidly, Modern C++ is an idiom adopted to work around the issues of raw memory management which Rust obviates out of the box.

What the author was writing was very standard introductory C++ taught in pretty much every C++ intro book I read in the early 2000s. That doesn't make it invalid C++, it makes it, "an older idiom".

To your more general point, C++ in the hands of an expert would clearly work better than presented here. I don't think that's an issue. The bigger question is, "Can C++ in the hands of a novice be as buggy as Rust in the hands of a novice".

Re: Comparing Rust and C++

#116

Post by humanrebar »

shin_lao wrote: post #99
humanrebar wrote: post #56

Earlier quoted context omitted.

> The bit about broken iterators is actually nice, but in this case could be avoided by handing an external function two const_iterator which then cannot be changed. No, I think you missed the point, which is iterator invalidation. http://stackoverflow.com/questions/16904454/what-is-iterator... . It's important to understand that various container methods can cause iterators to point to something else (or even nothin…

>1. This sort of for loop is idiomatic C++ code. No. This is C code. In C++ you write: std::vector a = { 1, 2, 3 }; std::cout You shouldn't be writing a lot of loops in C++. You should be using the algorithms as much as possible.

I'm aware of algorithms and espouse them, but you're not comparing apples to apples. The example is about mutating a collection while iterating over it:

  for(std::vector::const_iterator it=v.begin(); it!=v.end(); ++it) {
      if (*it
...you could do that with std::for_each and a lambda, or maybe some creative use of std::back_inserter, but you'd still have iterator invalidation problems.

The right way to do it might be to use a while loop that uses std::find_if to find the next value to insert, but I'm not sure how you'd arrive at that solution without thinking about iterator invalidation in the first place.

...and the point is that Rust effectively says "you can't iterate over a mutable collection like that" while a less battle-scarred C++ developer might not even notice the problem before deploying to production.

Re: Comparing Rust and C++

#117

Post by shmerl »

Jweb_Guru wrote: post #107
shmerl wrote: post #12

Earlier quoted context omitted.

What do you mean less common? Less commonly used or less commonly useful? Idiomatic C++11 discourages usage of raw pointers altogether. C++ introduced RAII ideas quite a long time ago, it's just in practice they weren't always followed and only in C++11 they were backed by standardized features from stdc++. Rust has an advantage of following this approach from the very beginning and not having all kind of legacy bagg…

To be clear: Rust has quite a few smart pointer types, but because Rust makes regular references completely safe, people just use those a lot of the time. For example, very few functions are written to take `Vec `s (the equivalent of C++'s `std::vector`), because they can simply take slices (`&[T]`) which are just a pointer and a length. Storing a slice in a structure isn't unsafe in Rust, so people do it all the tim…

Thanks for clarifying. That's good, since I assume using smart pointers is more expensive in Rust than using references, same as in C++.

Re: Comparing Rust and C++

#118

Post by SamReidHughes »

gilgoomesh wrote: post #15
claudius wrote: post #6

It might be a good idea to compare C++ and Rust and not “C with Classes and no use of compiler options” and Rust. They do have a fair point about ugly template error messages, but the remaining issues are mostly moot: Freed memory issues can be avoided using std::unique_ptr and its siblings, lost pointers to local variables shouldn’t occur when using references instead of pointers, uninitialised variables are warned…

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

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

Re: Comparing Rust and C++

#119

Post by jjnoakes »

shin_lao wrote: post #99
humanrebar wrote: post #56

Earlier quoted context omitted.

> The bit about broken iterators is actually nice, but in this case could be avoided by handing an external function two const_iterator which then cannot be changed. No, I think you missed the point, which is iterator invalidation. http://stackoverflow.com/questions/16904454/what-is-iterator... . It's important to understand that various container methods can cause iterators to point to something else (or even nothin…

>1. This sort of for loop is idiomatic C++ code. No. This is C code. In C++ you write: std::vector a = { 1, 2, 3 }; std::cout You shouldn't be writing a lot of loops in C++. You should be using the algorithms as much as possible.

Don't use "std::endl" unless you intend to flush the stream (doubtful in this case). It's not a replacement or synonym for "\n".

Re: Comparing Rust and C++

#120

Post by Matthias247 »

steveklabnik wrote: post #114
humanrebar wrote: post #112

Earlier quoted context omitted.

You can as long as they are immutable objects. Again, you can't alias mutable references, even if they are of the exact same type. Maybe you should read this: http://doc.rust-lang.org/guide.html#traits

I believe your parent is referring to storing trait objects in something like Arc , which is not supported: currently, Arc requires T to be sized.

Similar, but not exactly:

As I said, the objective is to have access to one object (in it's native form or in an interface (supertype) form from different locations. For that you can can use Rc. To be able to mutate it you can add RefMut and end up with Rc>, e.g. Rc>. And now how do I get an Rc> or any other type like &mut TextBox back from that?

Post reply on HN