Live data from Hacker News

Comparing Rust and C++

kukuruku.co

71–80 of 139 posts

Re: Comparing Rust and C++

#71
post #45

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…

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

Re: Comparing Rust and C++

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

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?

Re: Comparing Rust and C++

#73
post #61

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.

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, and uses its own smart pointer classes). Not even templates, if you are using QObjects.

I know of noone that uses features such as RTTI.

Re: Comparing Rust and C++

#74
post #27
post #21

Earlier quoted context omitted.

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.

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 discussions like this, but in general it has a chilling effect on the subject being discussed. In this particular example, we need to know the deficiencies of Rust's allocation model, and there is much to be gained by discussing them and finding a workable solution. Shutting down the discussion with 'use the safety tools you already have or you're a foolish brogrammer' is not acceptable.

Re: Comparing Rust and C++

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

It's tricky and there is no one-language-to-rule-them-all because they have up- and downsides. C++ has the advantage of an incredible amount of code written in over the years that mostly works. It also executes fast. It's also easy to find developers for it. With the new addons to the specification it's even possible to write readable code with it.. However, it has a stupidly long, verbose and feature creepy standard…

    > [Go] It has the potential to surpass C++ in a few decades though, as it operates in the same domain (systems programming).
Nope, Go and C++ operate on different domains, Go is garbage collected and nobody will use it for low level system programming.

Re: Comparing Rust and C++

#76
post #49
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/

Are those annotations like Java's? http://doc.rust-lang.org/src/arena/lib.rs.html#353-363 I wish languages would let you say the whole file/module is special - for example, inline all functions.

Not sure about inlining, but if you put #![some_attribute(args)] at the top of a .rs file, it applies to the whole file.

Re: Comparing Rust and C++

#77
post #70

Earlier quoted context omitted.

I'm not saying it's not needed, but there's a huge chunk of the C++ world that doesn't do web development. The other things I mentioned are more generally useful. In particular, XML support probably needs to come before HTTP support. Not that I'd turn my nose up at standard HTTP support.

I recommend the libraries from CodeSynthesis for your XML and database needs. The documentation for both is superb, and the APIs are crisp and modern. JSON I'd go with either JSON Spirit (boost header dependency) or JsonCpp (git version[0], since there hasn't been a release in 3 and a half years. 1.0 was tagged recently though) For webdev I've personally used CppCMS, which is of good quality, although it is a framewo…

I know there are libraries out there; I was talking about getting more things standardized so programs can mix and match these libraries with fewer translation layers. For example, boost spirit is a bit out there for most projects.

Re: Comparing Rust and C++

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

Since that's undefined behavior anything (including and especially things worse than a segmentation fault) could happen.

Re: Comparing Rust and C++

#79
post #68

I've flagged this because not only is it an unfair characterization of C++, it's also using a version of Rust that is six months out of date. As a Rust fan, I don't think we need to resort to cheap shots. The language stands well enough on its own; misinformation and propaganda pieces won't get us anywhere.

If anything, the Rust community seems more concerned with only showing the good sides of its community than it is with only showing the good sides of Rust. That of course has its social/"political" advantages.

Re: Comparing Rust and C++

#80
post #22
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.

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