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

21–30 of 139 posts

Re: Comparing Rust and C++

#21

Post by seabee »

Animats wrote: post #9
seabee wrote: post #4

Earlier quoted context omitted.

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…

Ugh. This is what is wrong with any discussion with performance; someone who only ever builds CRUD apps wades into the conversation spouting junior level truisms and raises the noise floor for those of us who have done steps 1 thru 3. This isn't Stack Overflow, you aren't educating beginners, and even then there is no need to come to the comments with an axe to grind.

The compiler is not a magical fairy that optimises away the cost of memory allocation. You don't 'emulate an arena' with a vector of reference counted pointers, any more than you emulate a cheetah by painting spots on your body.

Nobody uses an arena because they are lazy or hate destroying objects; you still pay the cost if your objects have the Drop trait. You use them because you have a bunch of fixed size allocations all with the same lifetime, and - after profiling - you need to exploit that fact.

There will be unsafe code outside of Vec because you need to do four things:

- allocate a chunk of memory (for non-relocatable objects) - construct objects in portions of the memory of that chunk - destruct objects in each chunk - deallocate the chunks of memory

If Rust ever gets placement box we can do the whole thing safely, but IIRC there hasn't been a decision made nor any experimental implementation. Until then, if I need to turn off the safeties to get something done, I will - not to spite the condescending 'enlightened' who are above getting their hands dirty, but because if there is a business need and it can be done correctly with due diligence, it is not 'macho', it is the professional thing to do.

Re: Comparing Rust and C++

#22

Post by iopq »

sspiff wrote: post #16

While I love what Rust is trying to achieve and hate the many, many issues C++ has, this reads like a blatant propaganda piece. It's not comparing C++ with Rust, or at least not fairly. It's just listing the problems of C++ that Rust is trying to solve. Someone well versed in C++ could easily write an article with the same title and list a dozen reasons why C++ is superior.

It's not meant to be fair. Rust is created as a successor of C++ to completely overtake it everywhere.

Re: Comparing Rust and C++

#23

Post by adrusi »

wfunction wrote: post #13

How does Rust handle multiple object files and dynamic linking? It seems to me that pretty much all of these guarantees break down if the compiler can't see the source code for the whole program at once.

All the information needed to make these guarantees is the type information of all visible items in a translation unit ("crate").

Re: Comparing Rust and C++

#24

Post by verroq »

wfunction wrote: post #14
stinos wrote: post #10

Earlier quoted context omitted.

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

You really think auto and cbegin/cend make any difference here?

C++ programmers generally know the iterator invalidation rules though.

Re: Comparing Rust and C++

#25

Post by seabee »

EpicEng wrote: post #20
seabee wrote: post #4

Earlier quoted context omitted.

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/

>No, you can do that, and can do so safely (if you implemented the unsafe parts correctly, at least). That is equally true of C++; you're completely safe as long as you don't make any mistakes.

The entire C++ language is an unsafe block. I think you're trying to be funny, but you missed the point.

A concrete example of safety is that Rust can tell you if you reference memory from an arena after the arena goes out of scope. C++ can not.

Re: Comparing Rust and C++

#27

Post by simias »

seabee wrote: post #21
Animats wrote: post #9

Earlier quoted context omitted.

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…

Ugh. This is what is wrong with any discussion with performance; someone who only ever builds CRUD apps wades into the conversation spouting junior level truisms and raises the noise floor for those of us who have done steps 1 thru 3. This isn't Stack Overflow, you aren't educating beginners, and even then there is no need to come to the comments with an axe to grind. The compiler is not a magical fairy that optimise…

You make good points but the ad hominem is really not necessary.

Re: Comparing Rust and C++

#28

Post by frozenport »

shmerl wrote: post #12
Ericson2314 wrote: post #7

Earlier quoted context omitted.

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

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…

Not only legacy, many hardware vendors provide only C bindings leaving the management of resources to the user.

Re: Comparing Rust and C++

#29

Post by claudius »

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…

> Really? Then you're being naïve or obtuse. Both are common sources of bugs in C/C++. Accidental failure to handle all inputs (common when additional inputs are added after the handling code is written) and subtle typos with major consequences (see Apple's "goto fail" bug).

I don’t know, it seems reasonable to me to allow switch() not to handle all possible inputs and/or fall through. Requiring for() loops to always have a body also seems unnecessary, there are cases where everything fits nicely into the three standard elements.

Re: Comparing Rust and C++

#30

Post by adrusi »

EpicEng wrote: post #20
seabee wrote: post #4

Earlier quoted context omitted.

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/

>No, you can do that, and can do so safely (if you implemented the unsafe parts correctly, at least). That is equally true of C++; you're completely safe as long as you don't make any mistakes.

You're not wrong. Rust's contribution is that it statically verifies safety as much as possible, and when not possible, at least isolates all code which could potentially be unsafe. The means that if the program segfaults or has a data race or other unsafe behaviour, the programmer need only focus on code marked as unsafe to fix it.

In practice, most applications have hardly any unsafe code, delegating all of their unsafe behaviour to libraries that have presumably been thoroughly tested.

Post reply on HN