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

11–20 of 139 posts

Re: Comparing Rust and C++

#11

Post by anon1385 »

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…

>uninitialised variables are warned against when compiling with the (hopefully standard) -Wall -Werror

Not with GCC:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55873

Obviously it should warn you, but when one of the most popular C++ compilers has been failing to report uninitialised variables for 10 years then I think that the issue is worth raising. Clearly significant sections of the C++ community don't place a high value on the accuracy of these kinds of compiler warnings.

Re: Comparing Rust and C++

#12

Post by shmerl »

Ericson2314 wrote: post #7
shmerl wrote: post #3

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

Re: Comparing Rust and C++

#13

Post by wfunction »

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.

Re: Comparing Rust and C++

#14

Post by wfunction »

stinos wrote: post #10
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…

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?

Re: Comparing Rust and C++

#15

Post by gilgoomesh »

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 problem and Rust fixes it the same way.

> I don’t get the problems with "A dangerous switch" and "A broken semicolons", both seem sensible constructs

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

The purpose of Rust is to eliminate causes of careless and accidental errors by forcing you to do things the right way every time (rather than permitting lazy code).

Re: Comparing Rust and C++

#16

Post by sspiff »

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.

Re: Comparing Rust and C++

#17

Post by jahnu »

anon1385 wrote: post #11
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…

>uninitialised variables are warned against when compiling with the (hopefully standard) -Wall -Werror Not with GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55873 Obviously it should warn you, but when one of the most popular C++ compilers has been failing to report uninitialised variables for 10 years then I think that the issue is worth raising. Clearly signif…

In case anyone reading this is not familiar with it cppcheck is invaluable for finding such things.

http://cppcheck.sourceforge.net/

Re: Comparing Rust and C++

#18

Post by iopq »

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…

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

Re: Comparing Rust and C++

#19

Post by iopq »

TillE wrote: post #5
shmerl wrote: post #3

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

There have been actual real world examples of simple things like one line if statements and forgetting switches breaking code in production software and leading to VERY dangerous things. Especially in C/C++ code.

Re: Comparing Rust and C++

#20

Post by EpicEng »

seabee wrote: post #4
shin_lao wrote: post #2

If 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/

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

Post reply on HN