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

91–100 of 139 posts

Re: Comparing Rust and C++

#91

Post by Matthias247 »

humanrebar wrote: post #87
Matthias247 wrote: post #82

Earlier quoted context omitted.

It was my example, so I try to explain it a little more: There are quite a lot of cases where you would like to have things like this, but the example that's probably most straightfoward to understand is GUI systems: E.g. you have a generic `Widget`, the `IWidget`. Then you have some base-class `Container` which contains multiple other widgets (`list `). This might contain a reference to a `TextBox` (which is an impl…

I'm not aware of any production quality UI toolkits in Rust, but using traits and reference counting, Rust certainly supports this use case. In fact, it supports it more flexibly since different widgets don't have to share the same methods and data at all ... well, unless you want them to. And you can have your widgets implement more than one trait without having to combine them all into one giant class definition.

As soon as it supports storing trait objects in smart pointers and casting them. That's afaik still not the case.

Re: Comparing Rust and C++

#92

Post by steveklabnik »

nly wrote: post #51

Comparing languages with constraints which were laid in bedrock 30 years apart is fairly uninteresting. C++ is constrained by its compatibility with C, and always will be. Even C++17, which will be the biggest shift in the language ever, won't change this. I see very little evidence that most programmers actually care about the advantages Rust the language , as specified today, brings. I'd contest that these days the…

> more to do with these languages having sizeable and fairly decent standard libraries.

Rust actually has a pretty small standard library. Since we have a package management system so early in the lifetime of the language, we're leaning on that rather than having a large standard library.

Just two days ago, a PR was opened to remove four more things from the standard library: https://github.com/rust-lang/rust/pull/19820

Re: Comparing Rust and C++

#93

Post by steveklabnik »

humanrebar wrote: post #89
moomin wrote: post #58

I'd actually much rather read the opposite article: things that C++ excels at that Rust falls down on. I'm not an expert, but I think there's still allocation use cases C++ is better at.

Off the top of my head: * C++ has more robust compile-time meta-programming facilities, at least for the time being. * C++ can generally include C (well, C89) code as-is with no translation layer. Rust's FFI is pretty inoffensive, but it's more work than a #include * It's easier to do the really dangerous stuff if you have a good reason to. You can actually call push_back on a std::vector without invalidating your it…

C++ can also easily bind to libraries written in C++, while Rust cannot.

(those libraries need to expose a C interface for Rust to be able to)

Re: Comparing Rust and C++

#94

Post by wtetzner »

wfunction wrote: post #85
adrusi wrote: post #23

Earlier quoted context omitted.

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

I'm skeptical. Did they really make the type information stored in the ABI that advanced? Storing that kind of information outside of name mangling is a nontrivial feat (i.e. they'd need to rewrite the linker) and there's not a whole lot of information you can pack into name mangling.

I believe it's stored as the value of a special symbol in the object. I'm pretty sure I read about it somewhere, but I can't find the link now.

Does anyone know where to read about how Rust handles this?

Re: Comparing Rust and C++

#95

Post by kbart »

Dewie wrote: post #88
kbart wrote: post #80

Earlier quoted context omitted.

If I only get a penny every time I hear this "C++ is dead, the is going to replace it everywhere"..

The proposition is so far-fetched that I suspected that he was being facetious.

Normally I would think so too, but after so many overzealous articles about Rust on HN lately, it's hard to say.

Re: Comparing Rust and C++

#96

Post by gbersac »

blub wrote: post #61
JulianMorrison wrote: post #44

Earlier quoted context omitted.

C++ is like a fairytale forest, where staying on the one safe path through the woods (unmarked, known only by whispered lore) will give you a reliable system, but where you are constantly tempted by easier-looking diversions at the end of which lurk grues. And heaven help you if nobody has yet whispered to you the secret of the one safe path. Or if you consulted an older textbook, and the idiom it taught has a grue.

It's pretty well known that one should read Stroustrup's book and the Meyers books. If one were to learn in a vacuum, perhaps they would take a false path, but the community is in agreement on what the best learning resources are. As cute as your comment is trying to be, most languages cannot be learned by blindly trying things out, one should actually read a few books, try to be a part of the community and so on.

What are the reference of the books you are talking about ? Is it this two ones : http://www.amazon.fr/Effective-Modern-Specific-Ways-Improve-...

http://www.amazon.fr/C-Programming-Language-4th-ebook/dp/B00...

Note that they are both quite expensive. I am a student and it is not nothing to pay for this books.

Re: Comparing Rust and C++

#97

Post by okatsu »

outworlder wrote: post #73
blub wrote: post #61

Earlier quoted context omitted.

It's pretty well known that one should read Stroustrup's book and the Meyers books. If one were to learn in a vacuum, perhaps they would take a false path, but the community is in agreement on what the best learning resources are. As cute as your comment is trying to be, most languages cannot be learned by blindly trying things out, one should actually read a few books, try to be a part of the community and so on.

There's no such thing as an agreement. Perhaps on the learning resources, but not about which features should be used, which I think it is a better interpretation of the parent's comment. Take the C++ that's used on Chrome and compare to a Qt application. They'll be very different, and some features will be outright forbidden, depending on the codebase (for instance, Qt doesn't use copy constructors, or exceptions, a…

You not knowing anybody who uses RTTI doesn't mean much. I know people who use it. Our coding standard at work is mostly based on Meyers and Alexandrescu's guidelines.

Chrome and Qt's standards and design choices are their business and do not mean there is no recommended way to do things.

Re: Comparing Rust and C++

#98

Post by JulianMorrison »

outworlder wrote: post #72
JulianMorrison wrote: post #44

Earlier quoted context omitted.

C++ is like a fairytale forest, where staying on the one safe path through the woods (unmarked, known only by whispered lore) will give you a reliable system, but where you are constantly tempted by easier-looking diversions at the end of which lurk grues. And heaven help you if nobody has yet whispered to you the secret of the one safe path. Or if you consulted an older textbook, and the idiom it taught has a grue.

> C++ is like a fairytale forest, where staying on the one safe path through the woods (unmarked, known only by whispered lore) will give you a reliable system, but where you are constantly tempted by easier-looking diversions at the end of which lurk grues. This is the best description ever. May I use it?

Of course.

Re: Comparing Rust and C++

#99

Post by shin_lao »

humanrebar wrote: post #56
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…

> 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. No, I think you missed the point, which is iterator invalidation. http://stackoverflow.com/questions/16904454/what-is-iterator... . It's important to understand that various container methods can cause iterators to point to something else (or even nothin…

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

Re: Comparing Rust and C++

#100

Post by steveklabnik »

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…

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

Post reply on HN