6 ms·

C++ is getting compile time checks for type, bounds, and lifetime safety, which steals nearly all of Rust's safety thunder. See Herb Sutter's talk at CppCon:

by _b 11y ago

C++ is getting compile time checks for type, bounds, and lifetime safety, which steals nearly all of Rust's safety thunder. See Herb Sutter's talk at CppCon: http://herbsutter.com/2015/09/27/my-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.

meowface 11y ago
I love Rust, but I can't deny that this is a much more practical option for existing C++ projects.
dikaiosune 11y ago
But the core guidelines are optional -- which means that you'll still have the entirety of C/C++ footgun hell to watch out for, and decades of outdated teaching and learning materials. And very large codebases which could not be easily ported to a compiler that enforced those guideines. 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.
- unscaled 11y ago
  Looking at the presentation it looks like you can borrow a non-const reference (in rust parlance) several times, so there's no concurrency guarantee. 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.
  - dikaiosune 11y ago
    Absolutely, I didn't mean to say that improving C++ is bad (we sure as hell need it, esp. given how much of the world runs on C++), and C++14 and 17 have many exciting things coming. I just didn't think it was fair to say that the new standard(s) "steals nearly all of Rust's safety thunder," when several core promises of Rust's safety model aren't possible in C++ if you maintain backwards compatibility.
  - deleted 11y ago
    [deleted]
  - Manishearth 11y ago
    > there's no concurrency guarantee. 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-with-shared-mutability/ 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.
ubernostrum 11y ago
For most applications, moving to modern C++ is going to be a better option than rewriting in Rust. 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).
- cheez 11y ago
  Who rewrote in Lua instead of Python?
  - ubernostrum 11y ago
    Judging from comments I've seen here in discussions about Python 3, mostly companies who bet on a "write once, run forever" strategy and thought Python would never change.
    - cheez 11y ago
      Should have used C++ if they wanted that :D
- asdfaoeu 11y ago
  To be fair it's better than "rewrite everything in Rust"
- make3 11y ago
  I don't know that people don't choose C++ for performance reasons or for easy manipulation of low level stuff. Games, high performance computing, embedded and legacy software are the main applications of C++, aren't they? 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.
smrq 11y ago
I feel like C++ has turned into programming language Katamari Damacy. I wonder what it will look like when it rolls up Lisp?
- yoklov 11y ago
  It already has a turing complete pure functional sublanguage in it's templates. Probably closer to the worlds worst ML than a lisp, but it's still along the same lines.
- ajdlinux 11y ago
  This is one of the psychological barriers that keeps me from even trying to learn C++ - every time I hear friends talking about new C++ developments I can't help but feel that modern C++ is so incomprehensibly large that I'm just left paralysed.
  - adrianN 11y ago
    Modern C++ is not that huge, it just has lots and lots of weird corner cases and gotchas due to backwards compatibility. You can get reasonably proficient in a couple of weeks, just like any other programming language. You'll just be left with the nagging feeling that you don't understand _everything_ that might happen in your code. 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.
shmerl 11y ago
C++ still can't prevent things like iterator invalidation which are impossible in Rust. While I like modern C++, Rust really addresses a lot of problems with the proper design from the ground up, which C++ can't do. What Rust so far lacks is better OOP mechanisms. C++ beats Rust in that. For instance Rust is still missing something like virtual structs. See https://github.com/rust-lang/rfcs/issues/349 https://github.com/rust-lang/rfcs/issues/349
- iherbig 11y ago
  Genuine question: What do virtual objects enable that cannot be done through the Trait system?
  - shmerl 11y ago
    Problems that Rust can't now address are listed in that RFC. Such as sharing of fields between definitions for instance. Traits don't address that. See also these posts: * http://smallcultfollowing.com/babysteps/blog/2015/05/05/where-rusts-enum-shines/ http://smallcultfollowing.com/babysteps/blog/2015/05/05/wher... * http://smallcultfollowing.com/babysteps/blog/2015/05/29/classes-strike-back/ http://smallcultfollowing.com/babysteps/blog/2015/05/29/clas... * http://smallcultfollowing.com/babysteps/blog/2015/08/20/virtual-structs-part-3-bringing-enums-and-structs-together/ http://smallcultfollowing.com/babysteps/blog/2015/08/20/virt... * http://smallcultfollowing.com/babysteps/blog/2015/10/08/virtual-structs-part-4-extended-enums-and-thin-traits/ http://smallcultfollowing.com/babysteps/blog/2015/10/08/virt...
    - Manishearth 11y ago
      Note that while many OOP patterns are hard to express in Rust, there are equivalent patterns that handle the use cases. 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.
roca 11y ago
It remains to be seen whether that approach will guarantee memory safety. Last I checked, it had gaping soundness holes related to aliasing. (Note: most of the complexity and innovation in Rust is about controlling aliasing.) 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.
kibwen 11y ago
I'll be thrilled when Herb finally releases his lifetime enforcement tool, but until then it's too soon to celebrate. The mystery surrounding the details of Herb's approach still raises unanswered questions regarding the soundness and practicality of such a tool. 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_c14_by_default_herb_sutter/cvd6hpt?context=1 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.
- pjmlp 11y ago
  It is available to VS 2015 Update 1 users.
  - kibwen 11y ago
    I don't believe it is, unless something's changed. To quote MSDN: "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 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-guidelines-checkers-available-for-vs-2015-update-1/ https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-core-gu...
    - pjmlp 11y ago
      I thought that the NuGet package already had a few updates since December.
      - kibwen 11y ago
        I don't have access to a Windows machine right this moment to check, but a cursory search of the internet gives no indication that this tool has been released in any subsequent update. If it had, you'd think there'd be some fanfare, or acknowledgement, or documentation, or experience reports from users, or anything.
jonalmeida 11y ago
Full support for Concepts[1] would also further add to the compiler checks as well. Although I believe this hasn't be confirmed when it'll come into the standard. Essentially, they're just Rust Traits. [1]: https://en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29 https://en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29

by _b 11y ago

meowface 11y ago

I love Rust, but I can't deny that this is a much more practical option for existing C++ projects.

dikaiosune 11y ago

But the core guidelines are optional -- which means that you'll still have the entirety of C/C++ footgun hell to watch out for, and decades of outdated teaching and learning materials. And very large codebases which could not be easily ported to a compiler that enforced those guideines. 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.

unscaled 11y ago
Looking at the presentation it looks like you can borrow a non-const reference (in rust parlance) several times, so there's no concurrency guarantee. 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.
- dikaiosune 11y ago
  Absolutely, I didn't mean to say that improving C++ is bad (we sure as hell need it, esp. given how much of the world runs on C++), and C++14 and 17 have many exciting things coming. I just didn't think it was fair to say that the new standard(s) "steals nearly all of Rust's safety thunder," when several core promises of Rust's safety model aren't possible in C++ if you maintain backwards compatibility.
- deleted 11y ago
  [deleted]
- Manishearth 11y ago
  > there's no concurrency guarantee. 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-with-shared-mutability/ 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.

ubernostrum 11y ago

For most applications, moving to modern C++ is going to be a better option than rewriting in Rust. 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).

cheez 11y ago
Who rewrote in Lua instead of Python?
- ubernostrum 11y ago
  Judging from comments I've seen here in discussions about Python 3, mostly companies who bet on a "write once, run forever" strategy and thought Python would never change.
  - cheez 11y ago
    Should have used C++ if they wanted that :D
asdfaoeu 11y ago
To be fair it's better than "rewrite everything in Rust"
make3 11y ago
I don't know that people don't choose C++ for performance reasons or for easy manipulation of low level stuff. Games, high performance computing, embedded and legacy software are the main applications of C++, aren't they? 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.

smrq 11y ago

I feel like C++ has turned into programming language Katamari Damacy. I wonder what it will look like when it rolls up Lisp?

yoklov 11y ago
It already has a turing complete pure functional sublanguage in it's templates. Probably closer to the worlds worst ML than a lisp, but it's still along the same lines.
ajdlinux 11y ago
This is one of the psychological barriers that keeps me from even trying to learn C++ - every time I hear friends talking about new C++ developments I can't help but feel that modern C++ is so incomprehensibly large that I'm just left paralysed.
- adrianN 11y ago
  Modern C++ is not that huge, it just has lots and lots of weird corner cases and gotchas due to backwards compatibility. You can get reasonably proficient in a couple of weeks, just like any other programming language. You'll just be left with the nagging feeling that you don't understand _everything_ that might happen in your code. 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.

shmerl 11y ago

C++ still can't prevent things like iterator invalidation which are impossible in Rust. While I like modern C++, Rust really addresses a lot of problems with the proper design from the ground up, which C++ can't do. What Rust so far lacks is better OOP mechanisms. C++ beats Rust in that. For instance Rust is still missing something like virtual structs. See https://github.com/rust-lang/rfcs/issues/349 https://github.com/rust-lang/rfcs/issues/349

iherbig 11y ago
Genuine question: What do virtual objects enable that cannot be done through the Trait system?
- shmerl 11y ago
  Problems that Rust can't now address are listed in that RFC. Such as sharing of fields between definitions for instance. Traits don't address that. See also these posts: * http://smallcultfollowing.com/babysteps/blog/2015/05/05/where-rusts-enum-shines/ http://smallcultfollowing.com/babysteps/blog/2015/05/05/wher... * http://smallcultfollowing.com/babysteps/blog/2015/05/29/classes-strike-back/ http://smallcultfollowing.com/babysteps/blog/2015/05/29/clas... * http://smallcultfollowing.com/babysteps/blog/2015/08/20/virtual-structs-part-3-bringing-enums-and-structs-together/ http://smallcultfollowing.com/babysteps/blog/2015/08/20/virt... * http://smallcultfollowing.com/babysteps/blog/2015/10/08/virtual-structs-part-4-extended-enums-and-thin-traits/ http://smallcultfollowing.com/babysteps/blog/2015/10/08/virt...
  - Manishearth 11y ago
    Note that while many OOP patterns are hard to express in Rust, there are equivalent patterns that handle the use cases. 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.

roca 11y ago

It remains to be seen whether that approach will guarantee memory safety. Last I checked, it had gaping soundness holes related to aliasing. (Note: most of the complexity and innovation in Rust is about controlling aliasing.) 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.

kibwen 11y ago

I'll be thrilled when Herb finally releases his lifetime enforcement tool, but until then it's too soon to celebrate. The mystery surrounding the details of Herb's approach still raises unanswered questions regarding the soundness and practicality of such a tool. 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_c14_by_default_herb_sutter/cvd6hpt?context=1 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.

pjmlp 11y ago
It is available to VS 2015 Update 1 users.
- kibwen 11y ago
  I don't believe it is, unless something's changed. To quote MSDN: "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 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-guidelines-checkers-available-for-vs-2015-update-1/ https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-core-gu...
  - pjmlp 11y ago
    I thought that the NuGet package already had a few updates since December.
    - kibwen 11y ago
      I don't have access to a Windows machine right this moment to check, but a cursory search of the internet gives no indication that this tool has been released in any subsequent update. If it had, you'd think there'd be some fanfare, or acknowledgement, or documentation, or experience reports from users, or anything.

jonalmeida 11y ago

Full support for Concepts[1] would also further add to the compiler checks as well. Although I believe this hasn't be confirmed when it'll come into the standard. Essentially, they're just Rust Traits. [1]: https://en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29 https://en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29