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

121–130 of 139 posts

Re: Comparing Rust and C++

#121

Post by chadzawistowski »

Matthias247 wrote: post #60
gnuvince wrote: post #50

Earlier quoted context omitted.

Three questions: 1. what is the technical difference between template and generics? 2. how do we know that what Rust has are generics? 3. considering that the Rust type system was recently demonstrated to be Turing-complete, how can it be less powerful than C++'s?

I'm not the person who can give an exact definition, but imho generics are more related to the type system (you can have types that refer to other types) whereas C++ templates can produce more or less arbitrary code. E.g. the field of template metaprogramming in C++ is not possible with generics. I'm personally not convinced that the extra possiblities and extra complexity of C++ templates vs. a good generics impleme…

Tangential, but I'd like to point out that you can achieve compile-time metaprogramming much more easily in D, which provides the entire language during compilation [1]. I find this to be much more straightforward than arcane uses of templates such as SFINAE [2].

[1] http://en.wikipedia.org/wiki/Compile_time_function_execution... [2] http://en.m.wikipedia.org/wiki/Substitution_failure_is_not_a...

Re: Comparing Rust and C++

#122

Post by pjmlp »

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.

Still, those are just two among many.

Re: Comparing Rust and C++

#123

Post by thwest »

wfunction wrote: post #13

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.

Like C++ interfaces that contain std::unique_ptr, you can encode Rust types in your mangled names during linking.

Re: Comparing Rust and C++

#124

Post by Rusky »

wfunction wrote: post #108
adrusi wrote: post #105

Earlier quoted context omitted.

It basically generates a header file from the source code and then stores it alongside the object data containing the type information of all public items.

So there's no run-time dynamic linking? Or is it possible, but only with additional metadata files present? Or maybe the assumptions are statically verified according to the interface and it is assumed that they are never broken by clients?

The last one. Types are stored as metadata in the object files, those types are verified at build time, and then assumed correct at run time.

Re: Comparing Rust and C++

#125

Post by claudius »

pnathan wrote: post #115
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…

> If there are new, delete or pointer arguments in functions in your code, you’re most likely doing it wrong. Candidly, Modern C++ is an idiom adopted to work around the issues of raw memory management which Rust obviates out of the box. What the author was writing was very standard introductory C++ taught in pretty much every C++ intro book I read in the early 2000s. That doesn't make it invalid C++, it makes it, "a…

> What the author was writing was very standard introductory C++ taught in pretty much every C++ intro book I read in the early 2000s. That doesn't make it invalid C++, it makes it, "an older idiom".

True. But that would suggest that we also consider Rust as it was taught in the early 2000s. I don’t think this would get us very far.

> The bigger question is, "Can C++ in the hands of a novice be as buggy as Rust in the hands of a novice".

Then it would be useful to firstly point out in the article that the matter of comparison is not the whole language but merely its usefulness to novices and to secondly consider the validity of such a comparison when deciding which language to use in a new project – if most people are novices for most of the time they use the language (e.g. in introductory numerical computing course), then clearly “novice friendliness” is a sensible measure, but otherwise it’s mostly a moot issue how hard the first two months are if you end up using it for the next ten years.

Re: Comparing Rust and C++

#126

Post by wfunction »

Rusky wrote: post #124
wfunction wrote: post #108

Earlier quoted context omitted.

So there's no run-time dynamic linking? Or is it possible, but only with additional metadata files present? Or maybe the assumptions are statically verified according to the interface and it is assumed that they are never broken by clients?

The last one. Types are stored as metadata in the object files, those types are verified at build time, and then assumed correct at run time.

Gotcha, thanks!

Re: Comparing Rust and C++

#127

Post by towelguy »

Dewie wrote: post #104
towelguy wrote: post #102

The one thing I don't like about Rust is the implicit return. Looking at code, it's easier to spot a missing/extra "return" than a missing/extra ";".

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.

Re: Comparing Rust and C++

#128

Post by blub »

gbersac wrote: post #96
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.

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.

I am talking about Effective C++, More effective C++ and Effective STL by Meyers and The C++ programming language by Stroustrup.

Effective Modern C++ is about the new C++11 and C++14 standards. I am reading it now, looks good so far.

If you can get one thing, maybe Stroustrup's book would be the best choice, but make sure you get the latest edition which includes C++11. Note that amazon.fr has the kindle versions at significant discount (there's also a bundle of Meyers' first three books) if you are ok with their DRM.

Re: Comparing Rust and C++

#129

Post by comex »

Matthias247 wrote: post #120
steveklabnik wrote: post #114

Earlier quoted context omitted.

I believe your parent is referring to storing trait objects in something like Arc , which is not supported: currently, Arc requires T to be sized.

Similar, but not exactly: As I said, the objective is to have access to one object (in it's native form or in an interface (supertype) form from different locations. For that you can can use Rc . To be able to mutate it you can add RefMut and end up with Rc > , e.g. Rc > . And now how do I get an Rc > or any other type like &mut TextBox back from that?

I think you could store objects of type Box> and then write a generic wrapper struct which holds an Rc> and derefs into the trait object.

Admittedly this is ugly, and unnecessarily slow. For a more general solution, I think the language would allow implementing some kind of RcTransformed type which, given 'T, U : Unsized?, Transform : Fn(&T) -> &U' (or possibly a more general type, but I think that would require HKT?), takes an Rc, calls the transform, and stores both the reference and the transformed reference, allowing direct access to the latter. This would require an unsafe implementation, but would be safe to use.

Alternatively, there may be some existing functionality like that that I just haven't heard of...

Re: Comparing Rust and C++

#130

Post by ekidd »

Matthias247 wrote: post #59
ekidd wrote: post #42

Earlier quoted context omitted.

These biased bashes against C++ that advertise rust get somewhere between boring and annoying recently. The main Rust community tries to discourage Rust "zealotry." For example, on /r/rust, the rules include: 4. When mentioning other languages, keep the discussion civil. No zealotry! Anyway, as for your other question: E.g. something like boost asio would be between hard to impossible to implement in Rust because the…

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 easiest way to store objects of varying size that implement a specific interface. Experienced Rust developers may be able to simplify this a bit.

Is this what you were thinking about? Or did you mean something else?

Post reply on HN