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

31–40 of 139 posts

Re: Comparing Rust and C++

#31

Post by Ygg2 »

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.

If by true you mean false then yes I agree.

There is a world of difference between this block/function is unsafe rest is enforced by compiler and everything written is unsafe, lets download third party program to check.

Re: Comparing Rust and C++

#32

Post by icebraining »

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…

Good reply; would be better without that small sentence after "really?", though :)

Re: Comparing Rust and C++

#33

Post by Ygg2 »

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…

There are certain classes of behavior that are safe but compiler flags them as problematic.

To get around this restriction you use unsafe block or function.

Re: Comparing Rust and C++

#34

Post by sspiff »

iopq wrote: post #22
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.

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 they are trying to achieve, but I'm realistic enough that it won't be perfect.

Re: Comparing Rust and C++

#35

Post by halayli »

One of the main problems of C++ is that programmers treat it as C with classes because that's what it feels like at the surface. They think they know it because it feels like C and many decide not to learn its patterns and details. From the examples given, it's clear that the author is not very familiar with C++ and is also comparing Rust to C++98 which is not fair. C++11 is almost a new language.

Re: Comparing Rust and C++

#36

Post by Matthias247 »

These biased bashes against C++ that advertise rust get somewhere between boring and annoying recently. Yes, Rust has some interesting safety features that prevent some issues that you can run into with C++ (but not all). And yes, most of us will agree that header files suck and the rust approach here is nicer. That template error message are also PITA is also well known - but on the other hand templates are different (and more powerful) than generics.

On the other hand there are still a few constructs that I'm using using often enough in C++ that have currently no sane representation in Rust and that are astonishingly never mentioned in these articles:

- Everything that you use the friend keyword for. In Rust there is no way to access private data defined in other file (because that will automatically be another module which is also something I disagree with).

- Most things related to inheritance and interfaces. Composition is not always a better solution and Rusts traits seem still more suited for compile-time polymorphism than to runtime polymorphism. As an example try to find the equivalent of a `shared_ptr thing(new SomeThing()); shared_ptr iface = thing` in Rust. And yes, I want to be able to use both afterwards.

- Enabling concurrency. Some people might disagree but I think Rust is currently mostly good at preventing multithreading issues - but not at providing good and easy ways to enable it. E.g. something like boost asio would be between hard to impossible to implement in Rust because the safety mechanisms disagree with callbacks that mutate state or Future objects (which are similar to callbacks). For some things using low-level primitives like channels (aka queues) and creating new threads might be fine, but there are also enough cases where you would prefer a simple singlethreaded eventloop.

All in all I think there are still enough areas where I think Rust still is (unfortunatly) no real alternative for C++. And as long as that's the case I think writing such biased articles isn't fair.

Re: Comparing Rust and C++

#37

Post by keeperofdakeys »

claudius wrote: post #29
gilgoomesh wrote: post #15

Earlier quoted context omitted.

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

Rust allows you to not handle all possible inputs (but you must be explicit about it). If you look at the page again, you'll see "_ => 3", which is the rust version of a default case. This means that rust can tell if you if you forgot to handle a certain case.

As for the other things you list, I'd mark these more as "short-cuts", than features. It may take more effort to create code without them, but it gives parsing and code-readability improvements. Obviously the rust devs have made their decision here.

Re: Comparing Rust and C++

#39

Post by stinos »

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?

Compilation-wise: of course not. As an illustration of what is wrong with the code: yes. auto means you don't have to spell out the complete iterator definition. cbegin\cend is just a matter of const-correctness.

Re: Comparing Rust and C++

#40

Post by keeperofdakeys »

Matthias247 wrote: post #36

These biased bashes against C++ that advertise rust get somewhere between boring and annoying recently. Yes, Rust has some interesting safety features that prevent some issues that you can run into with C++ (but not all). And yes, most of us will agree that header files suck and the rust approach here is nicer. That template error message are also PITA is also well known - but on the other hand templates are differen…

Just on your last point, Rust does have the ability to do unsafe code (and many multi-threading primitives use these internally). The real question is, how can these be exposed to Rust in a way that plays nicely with other Rust code.

There are things like RefCell, which enables multiple threads to hold a reference to an object, with run-time checking of borrows. Or there are also explicit mutex wrappers that can be used. You could use these with channels, closures, or a callback system.

As Rust matures, we should see more of these kinds of features find themselves into the standard library.

Post reply on HN