See Herb Sutter's talk at CppCon: http://herbsutter.com/2015/09/27/my-talk-at-cppcon/
For most applications, moving to modern C++ is going to be a better option than rewriting in Rust.
It's also evident that Herb didn't bother trying to learn from Rust in the slightest back when devising this tool, see his own remarks on Reddit: https://www.reddit.com/r/cpp/comments/3m0d41/writing_good_c1...
Furthermore, the tool in question does nothing to improve C++'s capability for safe multithreaded programming, which IMO is Rust's actual (yet so often overlooked) ace in the hole.
"The package currently contains checkers for the Bounds and Type profiles. Tooling for the Lifetime profile demonstrated in Herb Sutter’s plenary talk (video at https://www.youtube.com/watch?v=hEx5DNLWGgA) will be made available in a future release of the code analysis tools."
https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-core-gu...
About 1% of the audience answered affirmatively to Herb's question about who was using some kind of static analysis tools.
Outside HN and Reddit circles, very few C and C++ developers, at least the typical enterprise ones, don't really care about such tools.
Back on my C++ days, just one company cared to pay for Insure++ and I was probably the only one using it.
This is way I am looking forward to use it eventually, but don't have high hopes for wider adoption from other C++ vendors.
I guess need to update to Update 2 when it goes to RTM ready.
So what I'm looking for from Herb Sutter is not just a set of good guidelines and tools to check for them, but also a proof --- or at least an argument --- that if the tool finds no errors in a piece of code then that code cannot be the source of memory safety bugs.
After all, lint was created to compensate for C's unsafety in 1979 and up until clang's introduction of static analysis, barely unused in the industry.
Still C++ isn't going anywhere and is the only native language with first class support in all mobile SDKs, so anything that helps improve its use is welcome.
Nowadays I only use C++ for hobby coding between Android and WP nowadays, or when I need to step out of JVM/.NET worlds, so I missed to follow up on it.
I wouldn't bet on that.
Companies which go with a language like C++ don't do it for "safety" or "performance" or reasons like that (at least, most of the time they don't). They go with it because they can get something written once, then run it for the next half-century and only have to spend engineering time on new features and the occasional critical bug. Telling them they need an intrusive rewrite of their entire codebase to use modern practices will simply result in either (A) no action taken (most likely) or (B) the rewrite happening in a language that isn't C++.
This is incidentally what happened with quite a few significant Python codebases in the 2/3 transition -- rather than rewrite their code to Python 3 standards, they said "eh, we're rewriting anyway, let's go to Lua" (most often, though some other languages were the "let's go to" option as well).
Some people on this website seem to blow the python 2/3 transition fairly out of proporotions.. Python 3 is really extremely similar to Python 2, and there are great tools to convert Python 2 code to Python 3 and vice versa.
I've tried Pasteurize (part of python-future) but it just leaves the "yield from" statements in place, giving syntax errors. And 3to2 does even less, and seems to mostly be a framework for building tools like Pasteurize.
I know this isn't easy, but JavaScript people do it with ES6 transpilers, and ES6 is more different from ES5 than Python 3 is from Python 2.
In case you want to see the scripts I use to change the python3 code to python 2 and make it work with pip:
https://github.com/JelteF/PyLaTeX/blob/master/convert_to_py2...
See also these posts:
* http://smallcultfollowing.com/babysteps/blog/2015/05/05/wher...
* http://smallcultfollowing.com/babysteps/blog/2015/05/29/clas...
* http://smallcultfollowing.com/babysteps/blog/2015/08/20/virt...
* http://smallcultfollowing.com/babysteps/blog/2015/10/08/virt...
To give some context on those blog posts; they exist to figure out how to add single inheritance to Rust. One of the strongest arguments for single inheritance in Rust is "Servo and similar things need it to model the DOM". I.e; the strongest argument out there is that modelling cross-language things with languages that _do_ have single inheritance is hard.
That's not a very strong argument. That's a pretty niche use case (which Servo itself has moved past; we have a setup emulating inheritance that works pretty ok now).
So while I do agree that Rust can't model these patterns easily; I'm skeptical that that can be an issue for the large majority of Rust users.
May be there are, but they far from trivial, and with the current level of documentation they are in the realm of some obscure hacks rather than straightforward part of the language. Which is a disadvantage. May be when The Book will cover OOP topics in depth and explain such patterns, or there will be some other dedicated documentation on this topic, things could become more clear.
I don't think so. Rust encourages a certain style of designing code, using enums and traits. Almost all the time this suffices.
My comment was at the macro level; I'm not saying that an OOP pattern will have an equivalent in Rust, I'm saying that if you look at the larger use case you can design your code in idiomatic Rust to avoid it.
As I said, may be you can, but it's far from trivial and unless you know how to do it already, coming up with such approaches isn't something that one who just learns the language would be focusing on. You yourself said above, that it's hard. And unlike languages like C++ where OOP approaches are very well documented, Rust documentation lacks such kind of information at present.
I said modeling single inheritance is hard. That's a very niche use case; basically only crops up when writing an interpreter for a language with single inheritance (and in cases like Servo's DOM)
> unless you know how to do it already, coming up with such approaches isn't something that one who just learns the language would be focusing on
Again, it's not a thing that you do as a drop-in for inheritance. I'm saying that the regular approach (i.e. using traits and enums idiomatically) to designing your application in Rust will cover the use cases for inheritance, differently.
Basically, don't try to write Rust code as if it's C++ or Java and stuff should work out.
That said, the second draft of the book is placing a lot more emphasis on understanding how to write Rustic abstractions.
Then may be there should be one like that :) May be it's just my personal impression, but I feel that such kind of documentation now is lacking.
OOP in Rust shouldn't necessarily focus on comparison with other languages (though explaining key differences would be very helpful). But it at least should explain common use cases that OOP expects the language to cover and approaches that Rust proposes for them.
Something like this would very useful in The Book (or some other book): https://lwn.net/Articles/548560/
I will be happy if Rust's main impact on history will have been to showcase how to get those safety features into a practical language, and by extension improvements to C++, but I still think that the steps C++ is taking seem a lot less safe than what Rust has achieved by completely ignoring backward compatibility with C++98. See, for example, the compiler-enforced concurrency safety that Rust provides. I haven't read the core guidelines recently or in depth, but IIRC that's not a stated goal of the project.
You would have to break compatibility with too much existing code to get the same level of strictness as Rust, so that's reasonable, but yeah, it's hard to imagine that C++ will be as safe as Rust. I'm glad these features are being pushed through though.
Doesn't even have to do with concurrency. This leads to iterator invalidation and many other problems in single threaded code. In fact, Rust's "standard" concurrency guarantee (with regular, non-scoped threads) doesn't deal with the mutable aliasing rule; it works with the ownership rule more or less exclusively. Even if mutable aliasing was allowed in Rust, you could still build the same safe threading system assuming that borrows are still scoped[1].
The mutable-alias guarantee is more of a "don't let the rug be pulled out from under me". While this is something that's more obviously a problem in threaded situations where a mutation from a different thread can pull the rug out from under you, a function call in complex code that mutably aliases can cause the same issue. The classic example of this is iterator invalidation; but it works with any type which contains a variable amount/type of things, and severe logical (non-memory-safety) issues can be caused with anything with invariants.
See: http://manishearth.github.io/blog/2015/05/17/the-problem-wit...
[1]: When I say "safe", I'm assuming that in this situation (the lack of rules against) mutable aliasing itself isn't causing any unsafety elsewhere that transitively leaks down and causes thread safety to go kablooey. As such it's a necessary and mostly sufficient system of rules; removing one rule will probably make the whole house tumble. However, the point was that Rust's thread safety doesn't directly derive from the mutable aliasing rule.
When all the soundness holes are closed, then we'll have to evaluate whether it's usable to program in. At the very least, Rust is years ahead here.
Even if those hold up, you have to consider whether rewriting your C++ code to fit the safe subset is actually worthwhile, compared to rewriting in Rust which gives you additional benefits.
Is it exception safe? Are my iterators always valid? Is this undefined behaviour?
So better keep a copy of the C++ standard open and keep reading whenever you feel unsure.