101–110 of 139 posts
Rust looks really promising. Unfortunately, the tooling just isn't there yet, it seems. Release a working plug-in for YouCompleteMe and I will switch overnight ☺
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.
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 ";".
Are there other issues that you had in mind?
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.
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…
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…
std::vector features(const Widget& w);
...
auto highPriority = features(w)[5];
processWidget(w, highPriority); //whoops, undefined behavior
Earlier quoted context omitted.
One thing important to keep in mind that unique and shared pointers are actually _much_ less common than borrowed pointers in Rust. I have little C++ experience, but I can borrowed pointers in Rust are used exactly like the unsafe pointers that would be used in the same situation in C. In other words borrowed pointers allow you to write the same code you would in C, but safer. [Other Rust features necessitate or stro…
What do you mean less common? Less commonly used or less commonly useful? Idiomatic C++11 discourages usage of raw pointers altogether. C++ introduced RAII ideas quite a long time ago, it's just in practice they weren't always followed and only in C++11 they were backed by standardized features from stdc++. Rust has an advantage of following this approach from the very beginning and not having all kind of legacy bagg…
Earlier quoted context omitted.
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.
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.
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.
Abe Books ( http://www.abebooks.com/ ) provides a good place to look for used copies of books. A significant portion of the books in my library have stamps on the pages indicating that they were discarded from really nice institutions.
Of course there are always free-to-read blogs, but unfortunately, good C++ blogs are harder to find than other, newer language blogs.
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…
You need some mutable objects (like socket or the object that contains socket) locally AND you need access to them in your continuation.
If you're planning on writing to objects from inside a continuation, while you also write to them from your main code as well, you're going to have to think things through pretty carefully in any language, or else the two writers will stomp on each other. Rust has lots of tools for locking and controlling access.
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 a runnable example using Rust's "play" server: http://is.gd/bQOY3o
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.
Anyway, is this what you were thinking about? Or did you mean something else?