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

131–139 of 139 posts

Re: Comparing Rust and C++

#131

Post by iopq »

sspiff wrote: post #34
iopq wrote: post #22

Earlier quoted context omitted.

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

Yes, but everyone knows that it won't do that, and anyone who doesn't have brain freeze from the Rust Kool Aid understands that in programming languages, it's never so clear cut. I realize that Rust was designed to address the issues with existing systems programming languages, but surely it has flaws, tradeoffs and small annoyances, like every other programming language. I really like Rust and see the value in what…

Of course it does, but then it wouldn't be a comparison of C++ to Rust as much as a list of things Rust doesn't do well yet.

Re: Comparing Rust and C++

#132

Post by louiz »

humanrebar wrote: post #116
shin_lao wrote: post #99

Earlier quoted context omitted.

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

Actually the simplest way to dix that code ils to write

it = v.push_back(5-*it);

Re: Comparing Rust and C++

#133

Post by Animats »

seabee wrote: post #74
simias wrote: post #27

Earlier quoted context omitted.

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

In the cold light of day I agree, but we're not robots; discussions have an emotional aspect to them and sometimes an emotional response needs to be expressed. You can't be that person who tells everyone "you're doing it wrong" unless you really know for sure they are, and even then you shouldn't make them feel bad about it. It's worse when the subject is a nascent project and people's ideas are forming out of discus…

Rust is a new language. Its designers are close to solving the problems they set out to solve, but they haven't fully succeeded yet. Heavy use of "unsafe" indicates that there are things you can't properly express in the language, or can only express inefficiently.

It's worthwhile to separate the two. If you can't do it at all, there's a problem with expressiveness. If you can't do it fast, there's a problem with performance. It's useful to try to do things without using "unsafe" to cheat the system. Then you find out what the language needs to do faster. That's a trouble spot to be identified. There may be an optimization which leads to a safe and fast solution. Or there may be a way to make something checkable so that it's not necessary to do something unsafe.

Re: Comparing Rust and C++

#134

Post by Matthias247 »

ekidd wrote: post #130
Matthias247 wrote: post #59

Earlier quoted context omitted.

Regarding the futures: These are futures that you only can synchronously wait on (like what is currently available as std::future). However there is no possibilty to attach continuations that run when the value of the future is available. E.g. like the C++17 concurrency proposals, C#'s `Task` type or Javas `CompletableFuture`. These all rely on storing some kind of callback or closure inside the Future. That's not ea…

This will only work "safely" with garbage-collected or ref-counted types and these do still not seem to work for interfaces. I'm not quite sure if I understand the problem you're describing. I can definitely share mutable objects between threads, and I can do so using abstract traits (aka "interfaces"). Here's an example: https://gist.github.com/emk/acdf3ab9c79ba1abe6d2 I had to use a "box" here, because that's the e…

The part that your example is missing is that one side uses the trait object (Common) whereas the other side uses the "normal" type (Foo or Bar) or another trait object view of the object. And the be able to cast between such "smart-boxed" types after you acquired one of them.

See the disucssion a little bit below for examples with Rc (it's the same problem but within a thread instead of between threads).

Re: Comparing Rust and C++

#135

Post by beached_whale »

mike-cardwell wrote: post #71
pjmlp wrote: post #45

Earlier quoted context omitted.

> You can use a std::unique_ptr after it is assigned to something else. That's basically a use after free. While true, you can make it throw in such scenarios. I wouldn't be surprised if the debug builds of modern C++ compilers wouldn't do it already.

Here is some example code showing the problem: http://pastebin.com/6wu7bcrF I compiled it using both: g++ -std=c++14 -Wall -Wextra -g test.cpp -o test clang++ -std=c++14 -Wall -Wextra -g test.cpp -o test GCC v4.9.1 and Clang v3.5.0. Under neither case did it supply any warnings at compile time. In both cases it segfaults when it hits the second std::cout whilst running.

-Weverything on clang is what you want

Re: Comparing Rust and C++

#136

Post by AlisdairO »

shmerl wrote: post #117
Jweb_Guru wrote: post #107

Earlier quoted context omitted.

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

Reference counted smart pointers are more expensive than regular references in rust, but not as expensive as those in C++: Regular Rc pointers live on a single thread, and so don't have to use atomic increment/decrement like they do in C++. In addition, Rust's support for borrowing means that when passing smart pointers around you typically don't need to increment/decrement the pointer at all - because the compiler statically enforces that the borrowed reference lives for a shorter time than the smart pointer it's borrowed from.

Re: Comparing Rust and C++

#137

Post by Dewie »

towelguy wrote: post #127
Dewie wrote: post #104

Earlier quoted context omitted.

If you put an "extra" (unintended) semicolon on the last expression, the function will return Void/Unit: if this doesn't agree with the given type of the function, then there will be a compiler error. If you forget a semicolon, then the type of the function will become the type of the last expression, which will again make the compile complain. Are there other issues that you had in mind?

The C++ will complain as well, the issue is ";" is 6 times less characters than "return" and so, easier to overlook.

I think I'd rather have that problem than this problem:

    if (cond); //oops, a semicolon
        alwaysHappens();
, thank you very much.

Re: Comparing Rust and C++

#138

Post by mike-cardwell »

beached_whale wrote: post #135
mike-cardwell wrote: post #71

Earlier quoted context omitted.

Here is some example code showing the problem: http://pastebin.com/6wu7bcrF I compiled it using both: g++ -std=c++14 -Wall -Wextra -g test.cpp -o test clang++ -std=c++14 -Wall -Wextra -g test.cpp -o test GCC v4.9.1 and Clang v3.5.0. Under neither case did it supply any warnings at compile time. In both cases it segfaults when it hits the second std::cout whilst running.

-Weverything on clang is what you want

That's a useful option to know, thanks. However, it still didn't detect the problem being discussed.

Re: Comparing Rust and C++

#139

Post by mholub »

steveklabnik wrote: post #100
sspiff wrote: post #34

Earlier quoted context omitted.

Yes, but everyone knows that it won't do that, and anyone who doesn't have brain freeze from the Rust Kool Aid understands that in programming languages, it's never so clear cut. I realize that Rust was designed to address the issues with existing systems programming languages, but surely it has flaws, tradeoffs and small annoyances, like every other programming language. I really like Rust and see the value in what…

> surely it has flaws, tradeoffs and small annoyances, like every other programming language. Rust core team member here: it absolutely does. Rust is _far_ from perfect, as much as I love it. Anyone who tells you Rust has no flaws is lying.

Can you describe in few words which flaws do you see in rust?
Post reply on HN