7 ms·

C++ Lifetime profile v1.0 posted

91 points by nikbackm 8y ago

IloveHN84 8y ago
Good guy Herb!
Spartan-S63 8y ago
I don’t know the real narrative driving so much investment in safe C++, but it does appear that Rust is really driving C++ in this respect.
- imglorp 8y ago
  Not everyone gets to write new things :) There's a ton of existing codebases where there's no appetite for a rewrite from scratch, but some incremental improvements can be tolerated.
- 72deluxe 8y ago
  I am not sure about Rust causing this. I think the safety has long been a goal of any C++ developer, particularly with large projects. I mean, I've touched or looked at rust yet safe C++ is very very high on my list of "important things" and amongst my C++ developer colleagues, none of which have looked at Rust either.
  - childintime 8y ago
    The alternative is to write new stuff in Rust and link as usual. And get the many other benefits beside lifetimes. Specially if, as you say "safe C++ is very very high on my list of \"important things\"". The safety Rust offers makes you a better programmer, because in C++ your focus is partially (mostly?) tied up to provide guarantees Rust provides for free. I presume you can't imagine the breath of fresh air that is. The only price to pay is give up objects, and that may be a good thing.
    - jjnoakes 8y ago
      > The only price to pay is give up objects There's other prices to pay, of course. Rust doesn't target as many systems as C++, for example. Adding Rust to a project means someone has to update your build/ci/cd/etc infrastructure, your development machines need rust installed and kept up-to-date, and your developers have to become familiar with Rust. There will also probably be pain points when crossing the C++ <-> Rust boundary (since you have to do so at mostly the C level) - you lose lifetime information, you have to convert data types back and forth, etc. These may or may not be show-stoppers, but there's certainly more than near-zero friction in running and maintaining a C++ code base with incremental pieces rewritten in Rust. (I'm a huge Rust fan, btw).
      - blub 8y ago
        What's a nice way to call Rust from C++? If the answer is through a C interface then I am (still) disappointed.
        pjmlp 8y ago
        It is. RustConf 2018 - Embedding Rust in C/C++ https://www.youtube.com/watch?v=x9acx2zgx4Q https://www.youtube.com/watch?v=x9acx2zgx4Q
        bluejekyll 8y ago
        You can make decent wrappers in both languages that provide a similar feeling so that you have a good C++ or Rust API over C. But yes, out of the box, there aren’t simple ways of exposing native interfaces across the language boundaries.
        jerf 8y ago
        It's worth pointing out there really isn't a such thing anyhow. We spent many decades with all our "cool, exotic" languages like Python and Perl and PHP and such just giving up and tying themselves to C semantics, so the C ABI could serve as a de-facto interchange format. But in what I think is a sign that the C dominance is finally starting to fade, more languages are getting away from that, and while they still need a C bridge, it's getting more and more isolated from the rest of the languages. The core problem is that the cross-language interface isn't just about "calling a function"; there's semantics around who owns what, who's responsible for deallocation, garbage collection, degrees of thread safety and memory boundaries, and on and on and on it goes. It is a bit of an illusion from the last several decades that there is any way for there to be a "generic cross-language interface", because under the hood everything was designed to either be "C memory semantics" or "C memory semantics plus whatever other stuff we can stick on that doesn't conflict with that". By contrast (and as the major exceptions to "everything is just C"), observe how "easy" it is for JVM-based or .Net languages to share objects, because the runtime environment makes almost all the hard decisions for you.
  - MaulingMonkey 8y ago
    > I am not sure about Rust causing this. I think the safety has long been a goal of any C++ developer, particularly with large projects. I'd guess that the yearning for safety in C++ may have been what's been driving Rust development, if anything. Rust's whole appeal to me is it takes the scattered, compiler-specific, opt-in, limited annotation-driven static analysis that I've always been retrofitting into existing C++ codebases and catching problems with... and replaced those checks with a unified, language-standard, opt-out, powerful and pervasive thing, that'll be in use from the get-go in Rust codebases.
- pjmlp 8y ago
  Rust ideas are indeed coming into C++ community, but safety was always part of the culture. A big part of C++'s culture was that we don't need to write unsafe C code unless we really must. That is why Bjarne designed it in first place, after his BCPL experience. The fact that many C refugees use C++ as pretty C, is a sad side effect of the copy-paste compatibility.
  - jjnoakes 8y ago
    > A big part of C++'s culture was that we don't need to write unsafe C code unless we really must In C++ you don't have to drop down to "unsafe C code" to lose lots of safety guarantees (like data races, iterator invalidation, danging pointers, use-after-free, use-after-move, etc)...
    - pjmlp 8y ago
      True, but you have missed the part that makes C++ safer than C. - User defined types with invariants - templates, const, constexpr and if constexpr instead of macros - proper string types - proper vector types - type safe enumerations - many implicit conversions in C are compiler errors in C++ - RAII - contracts - generic data structures The iterator invalidation is easy to find out in compilers like Visual C++, their STL implementation can be customized to validate iterator invariants. The danging pointers, use-after-free, use-after-move mentioned by you are the purpose of this proposal. I was an early C++ adopter in 1992, LLVM rejuvenated language research in 2003, DirectX and Metal shaders are a C++ dialect, AUTOSAR has migrated from C to C++14 only two years ago, NVidia GPUs since Volta (2017) are now being designed to run C++ code efficiently. A time frame of about 30 years for C++ to become widespread as it is. I am all for Rust or similar language to replace C++ and do away with C copy-paste culture, but I am not throwing away all my code just because. So yeah, it isn't perfect, but it surely is way better than plain C coding and the community does try to promote not doing C in C++. CppCon 2015: Kate Gregory “Stop Teaching C" https://www.youtube.com/watch?v=YnWhqhNdYyk https://www.youtube.com/watch?v=YnWhqhNdYyk
      - jjnoakes 8y ago
- rwj 8y ago
  This is part of the ongoing evolution. The introduction of move operations and smart points in C++11 really started a movement towards "safe by design" (Herb Sutter's words).
- steveklabnik 8y ago
  This proposal and Rust's guarantees are different. For example: > We do not attempt to address all aliasing cases or make concurrency safety guarantees. Programmers are still responsible for eliminating race conditions. Some stuff is the same: > The analysis is local each to function (no whole program analysis), Some stuff is in the middle: > We do not currently attempt to check of the internals of Owner types, including that we do not attempt to validate the correctness of pointer-based data structures. (Often, pointer-based data structures in Rust are implemented with unsafe, which isn't checked. Rust's lifetimes also don't interact with owners, in a sense. But Rust's ownership system does, which is together as one thing in this paper. But all of this is possibly splitting hairs.) This is based on a CFG; Rust's historically has been based on lexical scope, but is moving to a CFG soon (NLL is slated for 1.31.) Regardless, I'm glad to see anything that makes C++ safer, regardless of motivations. It's all about making software better, not cheering on the home team and booing the away team.
  - comex 8y ago
    Aliasing is a big one. One of the main reasons Rust’s borrow checker can be painful is that it doesn’t want you to have two mutable references to the same thing, anywhere in your code. In C++, on the other hand, mutable references are the norm, and it’s common to have a multitude of different references to the same object, handed out to any other object that wants to know about it. (And traditionally they wouldn’t even be ref-counted. “Modern C++” encourages the use of shared_ptr, which at least prevents the references themselves from going stale, but that doesn’t help if you have a temporary pointer into a sub-object derived from one reference, e.g. an element of a vector, and then someone invalidates the sub-object through another reference.) Well, this lifetime checker, to quote the paper, “aims for low false positives in ‘good’ code that follows modern C++ convention”. And for better or worse, that “modern C++ convention” doesn’t include a drastic rework towards Rust-style pervasive immutability and explicit locking (`RefCell`) if you want to mutate something shared. Nor does it do anything magical to work around the reasons Rust needs that. Indeed, there’s not much that can be done as long as you want to stick with a purely function-local analysis (which, for the record, Rust’s borrow checker is as well) – at least, not without using an even more elaborate system of manual annotations. So instead it gives up on dealing with those cases. Which is perfectly reasonable – it’s still going to do a lot of good by catching many common types of mistakes. On the other hand, it’s important to recognize that its limitations aren’t a matter of a few missing pieces or legacy constraints, things that can be easily patched up in the future. As it stands, the design fundamentally sacrifices the ability to make the kind of complete guarantees Rust’s borrow checker can, and that can’t change unless it’s willing to cause significantly more disruption for codebases and programmers.
usefulcat 8y ago
"I love C++. I also love safe code and not having to worry about dangling pointers and iterators and views. So I’ve been doing some work to make my life less conflicted" I love the honesty there :)
kvark 8y ago
> It aims to detect common local cases of dangling pointers/iterators/string_views/spans/etc Hmm, a good tool to have, but wouldn't be quite enough to sleep well, since it's only for "common cases".

91 points by nikbackm 8y ago

Good guy Herb!

I don’t know the real narrative driving so much investment in safe C++, but it does appear that Rust is really driving C++ in this respect.

imglorp 8y ago
Not everyone gets to write new things :) There's a ton of existing codebases where there's no appetite for a rewrite from scratch, but some incremental improvements can be tolerated.
72deluxe 8y ago
I am not sure about Rust causing this. I think the safety has long been a goal of any C++ developer, particularly with large projects. I mean, I've touched or looked at rust yet safe C++ is very very high on my list of "important things" and amongst my C++ developer colleagues, none of which have looked at Rust either.
- childintime 8y ago
  The alternative is to write new stuff in Rust and link as usual. And get the many other benefits beside lifetimes. Specially if, as you say "safe C++ is very very high on my list of \"important things\"". The safety Rust offers makes you a better programmer, because in C++ your focus is partially (mostly?) tied up to provide guarantees Rust provides for free. I presume you can't imagine the breath of fresh air that is. The only price to pay is give up objects, and that may be a good thing.
  - jjnoakes 8y ago
    > The only price to pay is give up objects There's other prices to pay, of course. Rust doesn't target as many systems as C++, for example. Adding Rust to a project means someone has to update your build/ci/cd/etc infrastructure, your development machines need rust installed and kept up-to-date, and your developers have to become familiar with Rust. There will also probably be pain points when crossing the C++ <-> Rust boundary (since you have to do so at mostly the C level) - you lose lifetime information, you have to convert data types back and forth, etc. These may or may not be show-stoppers, but there's certainly more than near-zero friction in running and maintaining a C++ code base with incremental pieces rewritten in Rust. (I'm a huge Rust fan, btw).
    - blub 8y ago
      What's a nice way to call Rust from C++? If the answer is through a C interface then I am (still) disappointed.
      - pjmlp 8y ago
        It is. RustConf 2018 - Embedding Rust in C/C++ https://www.youtube.com/watch?v=x9acx2zgx4Q https://www.youtube.com/watch?v=x9acx2zgx4Q
      - bluejekyll 8y ago
        You can make decent wrappers in both languages that provide a similar feeling so that you have a good C++ or Rust API over C. But yes, out of the box, there aren’t simple ways of exposing native interfaces across the language boundaries.
        jerf 8y ago
        It's worth pointing out there really isn't a such thing anyhow. We spent many decades with all our "cool, exotic" languages like Python and Perl and PHP and such just giving up and tying themselves to C semantics, so the C ABI could serve as a de-facto interchange format. But in what I think is a sign that the C dominance is finally starting to fade, more languages are getting away from that, and while they still need a C bridge, it's getting more and more isolated from the rest of the languages. The core problem is that the cross-language interface isn't just about "calling a function"; there's semantics around who owns what, who's responsible for deallocation, garbage collection, degrees of thread safety and memory boundaries, and on and on and on it goes. It is a bit of an illusion from the last several decades that there is any way for there to be a "generic cross-language interface", because under the hood everything was designed to either be "C memory semantics" or "C memory semantics plus whatever other stuff we can stick on that doesn't conflict with that". By contrast (and as the major exceptions to "everything is just C"), observe how "easy" it is for JVM-based or .Net languages to share objects, because the runtime environment makes almost all the hard decisions for you.
- MaulingMonkey 8y ago
  > I am not sure about Rust causing this. I think the safety has long been a goal of any C++ developer, particularly with large projects. I'd guess that the yearning for safety in C++ may have been what's been driving Rust development, if anything. Rust's whole appeal to me is it takes the scattered, compiler-specific, opt-in, limited annotation-driven static analysis that I've always been retrofitting into existing C++ codebases and catching problems with... and replaced those checks with a unified, language-standard, opt-out, powerful and pervasive thing, that'll be in use from the get-go in Rust codebases.
pjmlp 8y ago
Rust ideas are indeed coming into C++ community, but safety was always part of the culture. A big part of C++'s culture was that we don't need to write unsafe C code unless we really must. That is why Bjarne designed it in first place, after his BCPL experience. The fact that many C refugees use C++ as pretty C, is a sad side effect of the copy-paste compatibility.
- jjnoakes 8y ago
  > A big part of C++'s culture was that we don't need to write unsafe C code unless we really must In C++ you don't have to drop down to "unsafe C code" to lose lots of safety guarantees (like data races, iterator invalidation, danging pointers, use-after-free, use-after-move, etc)...
  - pjmlp 8y ago
    True, but you have missed the part that makes C++ safer than C. - User defined types with invariants - templates, const, constexpr and if constexpr instead of macros - proper string types - proper vector types - type safe enumerations - many implicit conversions in C are compiler errors in C++ - RAII - contracts - generic data structures The iterator invalidation is easy to find out in compilers like Visual C++, their STL implementation can be customized to validate iterator invariants. The danging pointers, use-after-free, use-after-move mentioned by you are the purpose of this proposal. I was an early C++ adopter in 1992, LLVM rejuvenated language research in 2003, DirectX and Metal shaders are a C++ dialect, AUTOSAR has migrated from C to C++14 only two years ago, NVidia GPUs since Volta (2017) are now being designed to run C++ code efficiently. A time frame of about 30 years for C++ to become widespread as it is. I am all for Rust or similar language to replace C++ and do away with C copy-paste culture, but I am not throwing away all my code just because. So yeah, it isn't perfect, but it surely is way better than plain C coding and the community does try to promote not doing C in C++. CppCon 2015: Kate Gregory “Stop Teaching C" https://www.youtube.com/watch?v=YnWhqhNdYyk https://www.youtube.com/watch?v=YnWhqhNdYyk
    - jjnoakes 8y ago
rwj 8y ago
This is part of the ongoing evolution. The introduction of move operations and smart points in C++11 really started a movement towards "safe by design" (Herb Sutter's words).
steveklabnik 8y ago
This proposal and Rust's guarantees are different. For example: > We do not attempt to address all aliasing cases or make concurrency safety guarantees. Programmers are still responsible for eliminating race conditions. Some stuff is the same: > The analysis is local each to function (no whole program analysis), Some stuff is in the middle: > We do not currently attempt to check of the internals of Owner types, including that we do not attempt to validate the correctness of pointer-based data structures. (Often, pointer-based data structures in Rust are implemented with unsafe, which isn't checked. Rust's lifetimes also don't interact with owners, in a sense. But Rust's ownership system does, which is together as one thing in this paper. But all of this is possibly splitting hairs.) This is based on a CFG; Rust's historically has been based on lexical scope, but is moving to a CFG soon (NLL is slated for 1.31.) Regardless, I'm glad to see anything that makes C++ safer, regardless of motivations. It's all about making software better, not cheering on the home team and booing the away team.
- comex 8y ago
  Aliasing is a big one. One of the main reasons Rust’s borrow checker can be painful is that it doesn’t want you to have two mutable references to the same thing, anywhere in your code. In C++, on the other hand, mutable references are the norm, and it’s common to have a multitude of different references to the same object, handed out to any other object that wants to know about it. (And traditionally they wouldn’t even be ref-counted. “Modern C++” encourages the use of shared_ptr, which at least prevents the references themselves from going stale, but that doesn’t help if you have a temporary pointer into a sub-object derived from one reference, e.g. an element of a vector, and then someone invalidates the sub-object through another reference.) Well, this lifetime checker, to quote the paper, “aims for low false positives in ‘good’ code that follows modern C++ convention”. And for better or worse, that “modern C++ convention” doesn’t include a drastic rework towards Rust-style pervasive immutability and explicit locking (`RefCell`) if you want to mutate something shared. Nor does it do anything magical to work around the reasons Rust needs that. Indeed, there’s not much that can be done as long as you want to stick with a purely function-local analysis (which, for the record, Rust’s borrow checker is as well) – at least, not without using an even more elaborate system of manual annotations. So instead it gives up on dealing with those cases. Which is perfectly reasonable – it’s still going to do a lot of good by catching many common types of mistakes. On the other hand, it’s important to recognize that its limitations aren’t a matter of a few missing pieces or legacy constraints, things that can be easily patched up in the future. As it stands, the design fundamentally sacrifices the ability to make the kind of complete guarantees Rust’s borrow checker can, and that can’t change unless it’s willing to cause significantly more disruption for codebases and programmers.

usefulcat 8y ago

"I love C++. I also love safe code and not having to worry about dangling pointers and iterators and views. So I’ve been doing some work to make my life less conflicted" I love the honesty there :)

kvark 8y ago

> It aims to detect common local cases of dangling pointers/iterators/string_views/spans/etc Hmm, a good tool to have, but wouldn't be quite enough to sleep well, since it's only for "common cases".