7 ms·

Could someone more knowledgeable than me compare and contrast this with Rust?

steveklabnik 11y ago
Rust core team member here, so beware of my bias. Compared to Rust, the C++ Core Guidelines: 1. Are still whitepapers, the tool has not been released. 2. Does not protect you from everything Rust does. 3. Incrementally improves on C++, rather than being a whole new language. These points have a number of implications. On the first point, all Rust code that exists today is already written in this style. As the tool still isn't released yet, essentially none (the tool is built based on some Microsoft work that they've been using internally, but other than that) of existing C++ code is following this. This means that even if _you_ use the tool, it doesn't mean your dependencies use the tool. Furthermore, how many people lament that they are still writing C++98 and not C++11, let alone C++14? Once the tool exists, how much code will actually use it? On #2, Herb has said in the past that "data races are off the table" and "dangling pointers in some circumstances are important." I _think_ that in the latter case, he means something akin to what we call "non-lexical borrows" in Rust, so it's not a big deal, but data races are. Rust's version of this concept also provides a foundation for compile-time concurrency errors, and this paper states "Our rule set for concurrency is not yet fully developed." We'll see what they come up with. On #3, this is both an advantage and a disadvantage, and ties into #1. If you have a large C++ codebase, it's not like you're just going to instantly port everything to Rust. Even Mozilla, with Firefox, is taking an incremental approach. This means this tool could have a lot of value for organizations which are using C++ today, in a way that Rust can't. However, as mentioned elsewhere in this thread, I'm not sure how much C++ code will actually pass the tool; rules like this can really change your design, so we'll see. EDIT: One more difference, we use "memory safety" in different ways. They describe their definition on the end of 3.0: > We say that a program is memory safe if every allocated object > is deallocated (once only) and no access is done through a pointer > (or reference, iterator, or other non-owning indirection) to an > object that has been deleted or gone out of scope (and thus > technically isn’t an object anymore – just a bag of bits). We usually describe memory safety in terms of "no data races". Theirs assumes single threading (see above about how concurrency is under-developed here) and we take it into context. Terminology is hard! Finally, I'm glad to see this project develop. I'm glad that the C++ committee is taking safety even more seriously than they have in the past. We all want better software with less bugs.
- sitkack 11y ago
  All valid points. For point 1, we should assume the tool is near release. Once it is, that point evaporates. > Once the tool exists, how much code will actually use it? Any number of the 10M+ C++ developers and probably a large number of Open Source projects. I remember something like 20% of C++ (projects|programmers) are using C++1/4. If half of those use the tool, that is still 1M programmers using a much safer system. Not the same as Rust, but better than the old way. In the near term, the total quantity of safer code will come from C++ adopting better static analysis than from the adoption of Rust, even if Rust is the better way. The biggest impediment to Rust adoption with C++ programmers is the non-ability to incrementally include Rust in a project. But this is true of C++ in general. Rust has the advantage of mind share, witnessing the mistakes of C++ and the ever increasing torrent of new programmers who will choose Rust over C and C++. Every problem that a C++ programmer has, a Rust programmer has. A Rust programmer just solves it slightly differently.
  - steveklabnik 11y ago
    Yeah. I _thought_ that I remembered the tool was supposed to come out two months ago, but I don't have any citation for that. I want to play with it! > the non-ability to incrementally include Rust in a project. Well, it just depends on how you do it. The approach Firefox is taking is to peel off chunks, re-write them in Rust, and then integrate that way. That said, better integration would be nice, and some people have some ideas about it.
    - Manishearth 11y ago
      For the isocpp guidelines to be truly safe on a C++ module similar work is required, really. Without the C-interface boilerplate, but plenty of old-C++ idioms will probably be incompatible with isocpp and you need to carefully work at abstraction boundaries. Less work, but nontrivial and of a similar kind.
    - sitkack 11y ago
      There are some great talks by Neil MacIntosh about the kinds of static analysis they are building into the tool. CppCon 2015: Neil MacIntosh “Static Analysis and C++: More Than Lint" https://www.youtube.com/watch?v=rKlHvAw1z50 https://www.youtube.com/watch?v=rKlHvAw1z50 CppCon 2015: Neil MacIntosh “Evolving array_view and string_view for safe C++ code"https://www.youtube.com/watch?v=C4Z3c4Sv52U https://www.youtube.com/watch?v=C4Z3c4Sv52U For something of this magnitude I wouldn't consider the project late until mid summer. Stroustrup's keynote at CppCon is a great overview of the semantics they want to support and the errors that the tooling with will prevent. https://www.youtube.com/watch?v=1OEu9C51K2A https://www.youtube.com/watch?v=1OEu9C51K2A
Manishearth 11y ago
Aside from what Steve mentioned: - Simpler lifetime system: Both a pro and a con, because some functions will not be expressible using "c++ borrowing" - No `Alias XOR mutability`, which in rust protects from memory issues and things like iterator invalidation. Not sure if isocpp addresses the segfault that can be caused by vector<int> v; // fill it up with elements int *ptr = v[3]; v.push_back(0); // may reallocate cout<<*ptr; // may segfault its been a while since I looked at the guidelines and I'm not sure of either of these points, take them with a grain of salt.
- pcwalton 11y ago
  It does rely on alias xor mutability.
  - Manishearth 11y ago
    Huh. I should read it again.

Rust core team member here, so beware of my bias. Compared to Rust, the C++ Core Guidelines: 1. Are still whitepapers, the tool has not been released. 2. Does not protect you from everything Rust does. 3. Incrementally improves on C++, rather than being a whole new language. These points have a number of implications. On the first point, all Rust code that exists today is already written in this style. As the tool still isn't released yet, essentially none (the tool is built based on some Microsoft work that they've been using internally, but other than that) of existing C++ code is following this. This means that even if _you_ use the tool, it doesn't mean your dependencies use the tool. Furthermore, how many people lament that they are still writing C++98 and not C++11, let alone C++14? Once the tool exists, how much code will actually use it? On #2, Herb has said in the past that "data races are off the table" and "dangling pointers in some circumstances are important." I _think_ that in the latter case, he means something akin to what we call "non-lexical borrows" in Rust, so it's not a big deal, but data races are. Rust's version of this concept also provides a foundation for compile-time concurrency errors, and this paper states "Our rule set for concurrency is not yet fully developed." We'll see what they come up with. On #3, this is both an advantage and a disadvantage, and ties into #1. If you have a large C++ codebase, it's not like you're just going to instantly port everything to Rust. Even Mozilla, with Firefox, is taking an incremental approach. This means this tool could have a lot of value for organizations which are using C++ today, in a way that Rust can't. However, as mentioned elsewhere in this thread, I'm not sure how much C++ code will actually pass the tool; rules like this can really change your design, so we'll see. EDIT: One more difference, we use "memory safety" in different ways. They describe their definition on the end of 3.0: > We say that a program is memory safe if every allocated object > is deallocated (once only) and no access is done through a pointer > (or reference, iterator, or other non-owning indirection) to an > object that has been deleted or gone out of scope (and thus > technically isn’t an object anymore – just a bag of bits). We usually describe memory safety in terms of "no data races". Theirs assumes single threading (see above about how concurrency is under-developed here) and we take it into context. Terminology is hard! Finally, I'm glad to see this project develop. I'm glad that the C++ committee is taking safety even more seriously than they have in the past. We all want better software with less bugs.

sitkack 11y ago
All valid points. For point 1, we should assume the tool is near release. Once it is, that point evaporates. > Once the tool exists, how much code will actually use it? Any number of the 10M+ C++ developers and probably a large number of Open Source projects. I remember something like 20% of C++ (projects|programmers) are using C++1/4. If half of those use the tool, that is still 1M programmers using a much safer system. Not the same as Rust, but better than the old way. In the near term, the total quantity of safer code will come from C++ adopting better static analysis than from the adoption of Rust, even if Rust is the better way. The biggest impediment to Rust adoption with C++ programmers is the non-ability to incrementally include Rust in a project. But this is true of C++ in general. Rust has the advantage of mind share, witnessing the mistakes of C++ and the ever increasing torrent of new programmers who will choose Rust over C and C++. Every problem that a C++ programmer has, a Rust programmer has. A Rust programmer just solves it slightly differently.
- steveklabnik 11y ago
  Yeah. I _thought_ that I remembered the tool was supposed to come out two months ago, but I don't have any citation for that. I want to play with it! > the non-ability to incrementally include Rust in a project. Well, it just depends on how you do it. The approach Firefox is taking is to peel off chunks, re-write them in Rust, and then integrate that way. That said, better integration would be nice, and some people have some ideas about it.
  - Manishearth 11y ago
    For the isocpp guidelines to be truly safe on a C++ module similar work is required, really. Without the C-interface boilerplate, but plenty of old-C++ idioms will probably be incompatible with isocpp and you need to carefully work at abstraction boundaries. Less work, but nontrivial and of a similar kind.
  - sitkack 11y ago
    There are some great talks by Neil MacIntosh about the kinds of static analysis they are building into the tool. CppCon 2015: Neil MacIntosh “Static Analysis and C++: More Than Lint" https://www.youtube.com/watch?v=rKlHvAw1z50 https://www.youtube.com/watch?v=rKlHvAw1z50 CppCon 2015: Neil MacIntosh “Evolving array_view and string_view for safe C++ code"https://www.youtube.com/watch?v=C4Z3c4Sv52U https://www.youtube.com/watch?v=C4Z3c4Sv52U For something of this magnitude I wouldn't consider the project late until mid summer. Stroustrup's keynote at CppCon is a great overview of the semantics they want to support and the errors that the tooling with will prevent. https://www.youtube.com/watch?v=1OEu9C51K2A https://www.youtube.com/watch?v=1OEu9C51K2A

Manishearth 11y ago

Aside from what Steve mentioned: - Simpler lifetime system: Both a pro and a con, because some functions will not be expressible using "c++ borrowing" - No `Alias XOR mutability`, which in rust protects from memory issues and things like iterator invalidation. Not sure if isocpp addresses the segfault that can be caused by vector<int> v; // fill it up with elements int *ptr = v[3]; v.push_back(0); // may reallocate cout<<*ptr; // may segfault its been a while since I looked at the guidelines and I'm not sure of either of these points, take them with a grain of salt.

pcwalton 11y ago
It does rely on alias xor mutability.
- Manishearth 11y ago
  Huh. I should read it again.