Comparing Rust and C++
kukuruku.co
Comparing Rust and C++
1–10 of 139 posts
Re: Comparing Rust and C++
#2If I understood correctly, it is not possible to manually manage memory in Rust and do things like memory recycling or pools?
Re: Comparing Rust and C++
#3Raw pointers is a bad example to compare to Rust. It's more like comparing C to it. If anything one should compare managed pointers like std::shared_ptr and etc, especially since the author mentions C++11.
Re: Comparing Rust and C++
#4If I understood correctly, it is not possible to manually manage memory in Rust and do things like memory recycling or pools?
No, you can do that, and can do so safely (if you implemented the unsafe parts correctly, at least). For example, here's an arena allocator crate: http://doc.rust-lang.org/arena/
Re: Comparing Rust and C++
#5Raw pointers is a bad example to compare to Rust. It's more like comparing C to it. If anything one should compare managed pointers like std::shared_ptr and etc, especially since the author mentions C++11.
Also failed to use std::thread and its related synchronization primitives.
And nobody who's been writing C or C++ for more than five minutes would actually make that mistake with a switch statement (omitting breaks). On the contrary, its fall-through behavior is often very convenient.
Re: Comparing Rust and C++
#6It 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 against when compiling with the (hopefully standard) -Wall -Werror, implicit copy constructors can either be deleted or this particular issue can be avoided by using a unique pointer (which has no copy constructor, hence the enclosing classes’ copy constructor is also deleted), I don’t quite get the issue with memory overlap, which is mostly an issue of a function receiving the wrong number set of arguments for the way it is written. 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. I don’t get the problems with "A dangerous switch" and "A broken semicolons", both seem sensible constructs and if you have bugs, you have bugs. Multithreading works as expected, except that using C++11 would probably have been nicer and one would have to explicitly make e.g. the lambda passed to std::thread mutable.
All in all, yes, Rust seems to be a nice language and in particular the template system looks somewhat more understandable, but please don’t write "Comparing Rust and C++" when you’re not actually using C++ but some weird mishmash of C and C++. If there are new, delete or pointer arguments in functions in your code, you’re most likely doing it wrong.
Re: Comparing Rust and C++
#7Raw pointers is a bad example to compare to Rust. It's more like comparing C to it. If anything one should compare managed pointers like std::shared_ptr and etc, especially since the author mentions C++11.
One thing important to keep in mind that unique and shared pointers are actually _much_ less common than borrowed pointers in Rust. I have little C++ experience, but I can borrowed pointers in Rust are used exactly like the unsafe pointers that would be used in the same situation in C. In other words borrowed pointers allow you to write the same code you would in C, but safer. [Other Rust features necessitate or strongly encourage different coding styles.] This leads me to conclude that C++ smart pointers either give you less ergonomics, or less safety, than Rust.
Re: Comparing Rust and C++
#8Raw pointers is a bad example to compare to Rust. It's more like comparing C to it. If anything one should compare managed pointers like std::shared_ptr and etc, especially since the author mentions C++11.
Also failed to use std::thread and its related synchronization primitives. And nobody who's been writing C or C++ for more than five minutes would actually make that mistake with a switch statement (omitting breaks). On the contrary, its fall-through behavior is often very convenient.
I missed a break in a switch a few weeks ago. I have been programming in C++ for more than a decade.
Re: Comparing Rust and C++
#9If I understood correctly, it is not possible to manually manage memory in Rust and do things like memory recycling or pools?
No, you can do that, and can do so safely (if you implemented the unsafe parts correctly, at least). For example, here's an arena allocator crate: http://doc.rust-lang.org/arena/
There's a lot of unsafe code in there.
The only allocation that really needs "unsafe" is "Vec", which is needed to have some way to convert raw storage into variable size arrays. Everything else could be built on top of "Vec".
If you want the effect of an arena, you can have all the objects in the arena owned by a master object, and all the links within the arena weak, using "std::rc::Weak". This is a reasonable way to do a GUI or a web page, where there's heavy interlinking to neighboring graphical items, but those links don't indicate ownership. When the window or page closes, just drop the master object and the arena goes away. Yes, you spend more effort on deallocation. That's not where the time goes in a GUI.
There's an argument for doing things that way, rather than sprinkling "unsafe" around the library. Make it solidly reliable first, then profile, then look into compiler optimizations to make it faster.
(There's a macho mindset with some programmers. They think they don't need all that checking. They're wrong. Put those guys (it's usually males who have that attitude) on fixing obscure bugs or doing crash dump analysis for a while. They'll learn.)
Re: Comparing Rust and C++
#10It 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…
Good points. Also, first paragraph says C++11 (too be honest, C++11 mode) yet first example has std::vector >::const_iterator. Where's auto, cbegin/cend ?
In short: none of the C++ code written in the article resembles what a well-trained, well-behaved C++ programmer uses. And the same cannot be said of the Rust code, I think. On the other hand: maybe the whole point of the article is something like 'you don't have to be super well-trained in Rust yet won't shoot yourself in the foot'.