4 ms·

I feel that TitaniC++ has ran into the iceberg of memory safety and complexity. Bjarne Stroustrup’s previous article which basically tried to minimize memory s

I feel that TitaniC++ has ran into the iceberg of memory safety and complexity. Bjarne Stroustrup’s previous article which basically tried to minimize memory safety because it was a subset of program safety shows that Standard C++ really doesn’t have a great answer. I feel C++ needs to do the following to be able to survive: 1. Adopt language epochs so that the language syntax and semantics can be evolved without having to fight backwards compatibility. For example, the integer promotion rules are very confusing and a source of bugs. 2. Adopt solid dangling reference analysis into the compiler itself (using language epochs above). Static analysis as an external tool or command line flag is not good enough. With Rust, C++ now has a free, popular competitor language that is also focused on creating zero overhead abstractions, but that can guarantee memory safety and which also doesn’t have a bunch of language warts. If C++ doesn’t come up with a good story real soon to deal with memory safety at the language level and deal with the mess of language complexity, it will be relegated to a legacy language.

varjag 4y ago
…on the other hand it doesn't take a PhD to write a linked list in C++.
- nezirus 4y ago
  ... on the third hand it's better not to roll your own list in any language ;-) Joking aside, some stuff are currently really hard in Rust, but the rate of change slowed down, and all I can see now is everyday ergonomic improvements, so there is hope for (slightly) simpler syntax in the future.
  - pclmulqdq 4y ago
    Doubly linked lists break one of the fundamental promises you make to the borrow checker: single ownership. I doubt they're going to get much easier.
    - cmrdporcupine 4y ago
      It's also just generally not a wise structure to be making or using in applications level development at this point. Vectors will outperform them most of the time, are more cache friendly, and easier to write these days. And Rust has already done the work of building collections you can already use, including some that can be used no-std in embedded/baremetal environments. And if you really need a linked-list type structure, and are competent to make it and use it properly/safely, unsafe {} is waiting for you.
      - pclmulqdq 4y ago
        You tend to see linked lists in places like operating systems, storage systems, and stackless asynchronous server systems. These kinds of linked lists actually do perform better than vectors in most cases. Specifically, linked lists do well when objects are: 1. Large, specifically 100s of bytes 2. Moved frequently between collections 3. Intrusively linked (meaning that the pointers are part of the struct, not a separate library) and 4. Never randomly accessed One size does not fit all when it comes to performance of list structures, unfortunately. In particular, large items tend to break standard library structures, since they are not the usual case.
        cmrdporcupine 4y ago
        Yes, hence why I said "applications level" development specifically. 99% of developers will never need to go this path. Those that do, they're already working down in unsafe land usually in embedded systems and OS development, and they need to think carefully about what they're doing. I'm personally not entirely sold on Rust's memory safety model, though I did learn to work with it when I was getting paid to work in it.
- karmakurtisaani 4y ago
  Linked lists are complicated. You can get something that compiles easily with C++, but to be sure it doesn't leak memory might require you to get that PhD after all.
  - pclmulqdq 4y ago
    Linked lists are a very simple data structure, and pretty much everyone can get them right. There haven't been any big memory safety CVEs to my knowledge around linked list manipulation. The same for binary trees. These pointer-based data structures are used a lot when you are manipulating large structs in C and C++, as they let you "move" then between data structures without copying a ton of memory.
    - planede 4y ago
      It's not exactly rocket science or even PhD worthy, but getting basic exception safety right around manual memory management can get tricky.
      - lenkite 4y ago
        Well..implementing them in "safe" Rust is not just tricky - it requires a super-brain.
    - eru 4y ago
      You can use unsafe in Rust to get basically the same guarantees for your simple linked list as in C++?
  - jcdentonunatco 4y ago
    If you need a PhD to avoid memory leaks, stop coding immediately, you don’t know what you are doing
    - pebal 4y ago
      Show an example of a lock-free concurrent stack freeing nodes memory.
- RcouF1uZ4gsC 4y ago
  I don’t think it takes a PhD to write an unsafe linked list in Rust. And an unsafe linked list in Rust would still be safer than the equivalent linked list in C++
  - goalieca 4y ago
    How would the equivalent linked list in c++ be unsafe? The problem with c++ was never writing simple data structures, but was writing complete programs without a single mistake in the informal contracts between functions. Static analysis tools and other crutches help but having a stricter ruleset to enforce is what makes rust a winner.
    - RcouF1uZ4gsC 4y ago
      The list itself would not be unsafe, but the usages of it could be. For example, iterator invalidation, access from another thread, etc that Rust would prevent you from doing even if you used unsafe to implement the linked list.
grumpyprole 4y ago
> Adopt language epochs I guess the issue has always been that no one can agree on particular language subsets? However, one could view projects such as Google's Carbon as precisely that. A restricted safer subset of C++ with a more succinct syntax.
criddell 4y ago
If you feel strongly about this, I suggest you get involved. This page lists a bunch of different ways you can participate: https://isocpp.org/std/meetings-and-participation https://isocpp.org/std/meetings-and-participation As far as epochs go, you’re not the only one: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1881r1.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p18...
- KptMarchewa 4y ago
  Why would you waste time on that? They will never break ABI now.
foxhill 4y ago
> I feel C++ needs to do the following to be able to survive [...] absolutely. unfortunately, saftey oriented proposals tend to focus on a weaker warning-esque approach ([[nodiscard]], contracts, etc.), which, in my opinion, will ultimately only make things worse. i'll stay away from my type-systems-are-great soapbox :) the refusal to break ABI, remove non-destructive moves, the strengthening of concepts more akin to their original proposal, are not even on the horizon of discussion, despite us having exemplars of all 3. it's perplexing, to say the least.
- pclmulqdq 4y ago
  The refusal to do an ABI break is a crazy move on the C++ committee's part. C++ without an ABI break loses performance, has a bunch of confusing features (eg bucket iterators in hash tables...), and completely prevents a lot of proposals that would make smart pointers work a lot better.
  - planede 4y ago
    Not entirely disagreeing there, but to clarify, breaking hash table iterator guarantees would be an API break, not merely an ABI break.
hulitu 4y ago
> With Rust, C++ now has a free, popular competitor language Rust is so oldtimer. C++ is at version 24 and counting.
dmitriid 4y ago
> Adopt language epochs so that the language syntax and semantics can be evolved without having to fight backwards compatibility. That's what Javascript got surprisingly right IMO: you can target the latest bleeding edge features, and still be able to compile and run them on 20-year-old browsers through code re-writing (aka transpilation) and polyfills [1] I often wish this was available for other languages, too. [1] Well, not all features because some if them are notoriously hard to polyfill (IIRC Proxies are one such unpolyfillable feature). And there's the huge issue of the entire world relying on just one guy: https://github.com/zloirock/core-js/blob/master/docs/2023-02-14-so-whats-next.md https://github.com/zloirock/core-js/blob/master/docs/2023-02...
- hulitu 4y ago
  > you can target the latest bleeding edge features, and still be able to compile and run them on 20-year-old browsers through code re-writing The problem with C++ is the other way: you can't compile 10 year old code because the language has "evolved".
  - pclmulqdq 4y ago
    You still can compile 10 year old code - it's fully backwards compatible. If you choose to write new code in the same way as you did in pre-11 C++, though, people might have a lot of questions for you.
    - pjmlp 4y ago
      Mostly backwards compatible.
deadbeeves 4y ago
That's not going to happen. There's just too much friction to reach consensus on how to move the language in that kind of direction. It's like trying to get a centipede to walk to the food when none of the legs can agree on the best path to take. Before that happens, it's much more likely that some other language that interoperates well with C++ will reach a useful state (with regards to IDE support and other tools) and will be embraced by the community. By "community" I don't just mean hobbyists, but the major members of the C++ committee: Microsoft, Google, Nvidia, Intel, etc. That language might be Rust or it might be some other language that's yet to appear. It might not even be a single language, but several. I personally think Rust is not a suitable successor to C++.
- nordsieck 4y ago
  > I personally think Rust is not a suitable successor to C++. If you don't mind, what do you think are the main reasons for that?
  - i_no_can_eat 4y ago
    One thing that rust doesn't (yet) have is a strong presence and toolbox for usage in scientific computing. In scientific computing, when speed matters, Fortran/C/C++ still very much rule and rust won't take their place anytime soon. Julia has a better chance at that, in fact.
  - deadbeeves 4y ago
    I'm still developing my opinion of Rust, but * It's too different. This is to be expected because it was never designed to be like C++. For example, if I have an OOP-heavy application, moving it over to Rust is not a matter of fixing up a few ideas here and there like it might be with, say, Java or C#. It calls for a redesign/rewrite. I don't think a memory safe C++ successor would need to be more like Rust than like C++. * The language is not substantially simpler than C++. I find traits to be particularly difficult to reason about and to follow, to the point that I find myself just trying to find the right incantation that will appease the compiler. And that complexity shows up at build time just like it does with C++.
- 4y ago
pjmlp 4y ago
Rust still needs to prove itself on being a GCC/LLVM alternative, CUDA, SYSCL, HPC and HFT compiler toolchains, MPI, AUTOSAR and MISRA standards, game console SDKs, mobile OS SDKs, .... C++ still has lot of momentum for the upcoming decades, regardless how much we would like to RIIR everything.
- adgjlsfhk1 4y ago
  I pretty strongly disagree with this. Rust doesn't replace all of C++; it only replaces some. Specifically, there's not a great reason to write a compiler in a language with manual memory management. HPC is also starting to move to higher level alternatives like Julia. Also AUTOSTAR/MISRA are funny to bring up because they are desparate and only semi-successful attempts to bring a semblance of safety to fundamentally unsafe languages. You get all of the safety of them (and more) in Rust with the 2 rules of 1. don't use unsafe. 2. have tests.
  - pjmlp 4y ago
    Julia is implemented in C++, and makes use of LLVM, written in C++. Apparently AUTOSAR and MISRA are relevant enough for Rust, that efforts are being made to allow a Rust certification subset as well.
    - adgjlsfhk1 4y ago
      Julia isn't primarily implemented in C++. Most of the implementation is in Julia (68%). About 25% is C/C++, but that could be changed if someone wrote a good enough compiler in a fast enough memory safe language. The rest is in a custom scheme dialect (femptolisp) and is in the process of being replaced by Julia (see JuliaSyntax.jl).
      - pjmlp 4y ago
        Waiting for the LLVM rewrite in Julia.
        4y ago
bregma 4y ago
> If C++ doesn’t come up with a good story real soon to deal with memory safety at the language level and deal with the mess of language complexity, it will be relegated to a legacy language. That's exactly the purpose of WG21 SG23, convened for the study of safety and security for C++26 and beyond. You can complain or you can join and influence the future.

varjag 4y ago

…on the other hand it doesn't take a PhD to write a linked list in C++.

nezirus 4y ago
... on the third hand it's better not to roll your own list in any language ;-) Joking aside, some stuff are currently really hard in Rust, but the rate of change slowed down, and all I can see now is everyday ergonomic improvements, so there is hope for (slightly) simpler syntax in the future.
- pclmulqdq 4y ago
  Doubly linked lists break one of the fundamental promises you make to the borrow checker: single ownership. I doubt they're going to get much easier.
  - cmrdporcupine 4y ago
    It's also just generally not a wise structure to be making or using in applications level development at this point. Vectors will outperform them most of the time, are more cache friendly, and easier to write these days. And Rust has already done the work of building collections you can already use, including some that can be used no-std in embedded/baremetal environments. And if you really need a linked-list type structure, and are competent to make it and use it properly/safely, unsafe {} is waiting for you.
    - pclmulqdq 4y ago
      You tend to see linked lists in places like operating systems, storage systems, and stackless asynchronous server systems. These kinds of linked lists actually do perform better than vectors in most cases. Specifically, linked lists do well when objects are: 1. Large, specifically 100s of bytes 2. Moved frequently between collections 3. Intrusively linked (meaning that the pointers are part of the struct, not a separate library) and 4. Never randomly accessed One size does not fit all when it comes to performance of list structures, unfortunately. In particular, large items tend to break standard library structures, since they are not the usual case.
      - cmrdporcupine 4y ago
        Yes, hence why I said "applications level" development specifically. 99% of developers will never need to go this path. Those that do, they're already working down in unsafe land usually in embedded systems and OS development, and they need to think carefully about what they're doing. I'm personally not entirely sold on Rust's memory safety model, though I did learn to work with it when I was getting paid to work in it.
karmakurtisaani 4y ago
Linked lists are complicated. You can get something that compiles easily with C++, but to be sure it doesn't leak memory might require you to get that PhD after all.
- pclmulqdq 4y ago
  Linked lists are a very simple data structure, and pretty much everyone can get them right. There haven't been any big memory safety CVEs to my knowledge around linked list manipulation. The same for binary trees. These pointer-based data structures are used a lot when you are manipulating large structs in C and C++, as they let you "move" then between data structures without copying a ton of memory.
  - planede 4y ago
    It's not exactly rocket science or even PhD worthy, but getting basic exception safety right around manual memory management can get tricky.
    - lenkite 4y ago
      Well..implementing them in "safe" Rust is not just tricky - it requires a super-brain.
  - eru 4y ago
    You can use unsafe in Rust to get basically the same guarantees for your simple linked list as in C++?
- jcdentonunatco 4y ago
  If you need a PhD to avoid memory leaks, stop coding immediately, you don’t know what you are doing
  - pebal 4y ago
    Show an example of a lock-free concurrent stack freeing nodes memory.
RcouF1uZ4gsC 4y ago
I don’t think it takes a PhD to write an unsafe linked list in Rust. And an unsafe linked list in Rust would still be safer than the equivalent linked list in C++
- goalieca 4y ago
  How would the equivalent linked list in c++ be unsafe? The problem with c++ was never writing simple data structures, but was writing complete programs without a single mistake in the informal contracts between functions. Static analysis tools and other crutches help but having a stricter ruleset to enforce is what makes rust a winner.
  - RcouF1uZ4gsC 4y ago
    The list itself would not be unsafe, but the usages of it could be. For example, iterator invalidation, access from another thread, etc that Rust would prevent you from doing even if you used unsafe to implement the linked list.

grumpyprole 4y ago

> Adopt language epochs I guess the issue has always been that no one can agree on particular language subsets? However, one could view projects such as Google's Carbon as precisely that. A restricted safer subset of C++ with a more succinct syntax.

criddell 4y ago

If you feel strongly about this, I suggest you get involved. This page lists a bunch of different ways you can participate: https://isocpp.org/std/meetings-and-participation https://isocpp.org/std/meetings-and-participation As far as epochs go, you’re not the only one: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1881r1.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p18...

KptMarchewa 4y ago
Why would you waste time on that? They will never break ABI now.

foxhill 4y ago

> I feel C++ needs to do the following to be able to survive [...] absolutely. unfortunately, saftey oriented proposals tend to focus on a weaker warning-esque approach ([[nodiscard]], contracts, etc.), which, in my opinion, will ultimately only make things worse. i'll stay away from my type-systems-are-great soapbox :) the refusal to break ABI, remove non-destructive moves, the strengthening of concepts more akin to their original proposal, are not even on the horizon of discussion, despite us having exemplars of all 3. it's perplexing, to say the least.

pclmulqdq 4y ago
The refusal to do an ABI break is a crazy move on the C++ committee's part. C++ without an ABI break loses performance, has a bunch of confusing features (eg bucket iterators in hash tables...), and completely prevents a lot of proposals that would make smart pointers work a lot better.
- planede 4y ago
  Not entirely disagreeing there, but to clarify, breaking hash table iterator guarantees would be an API break, not merely an ABI break.

hulitu 4y ago

> With Rust, C++ now has a free, popular competitor language Rust is so oldtimer. C++ is at version 24 and counting.

dmitriid 4y ago

> Adopt language epochs so that the language syntax and semantics can be evolved without having to fight backwards compatibility. That's what Javascript got surprisingly right IMO: you can target the latest bleeding edge features, and still be able to compile and run them on 20-year-old browsers through code re-writing (aka transpilation) and polyfills [1] I often wish this was available for other languages, too. [1] Well, not all features because some if them are notoriously hard to polyfill (IIRC Proxies are one such unpolyfillable feature). And there's the huge issue of the entire world relying on just one guy: https://github.com/zloirock/core-js/blob/master/docs/2023-02-14-so-whats-next.md https://github.com/zloirock/core-js/blob/master/docs/2023-02...

hulitu 4y ago
> you can target the latest bleeding edge features, and still be able to compile and run them on 20-year-old browsers through code re-writing The problem with C++ is the other way: you can't compile 10 year old code because the language has "evolved".
- pclmulqdq 4y ago
  You still can compile 10 year old code - it's fully backwards compatible. If you choose to write new code in the same way as you did in pre-11 C++, though, people might have a lot of questions for you.
  - pjmlp 4y ago
    Mostly backwards compatible.

deadbeeves 4y ago

That's not going to happen. There's just too much friction to reach consensus on how to move the language in that kind of direction. It's like trying to get a centipede to walk to the food when none of the legs can agree on the best path to take. Before that happens, it's much more likely that some other language that interoperates well with C++ will reach a useful state (with regards to IDE support and other tools) and will be embraced by the community. By "community" I don't just mean hobbyists, but the major members of the C++ committee: Microsoft, Google, Nvidia, Intel, etc. That language might be Rust or it might be some other language that's yet to appear. It might not even be a single language, but several. I personally think Rust is not a suitable successor to C++.

nordsieck 4y ago
> I personally think Rust is not a suitable successor to C++. If you don't mind, what do you think are the main reasons for that?
- i_no_can_eat 4y ago
  One thing that rust doesn't (yet) have is a strong presence and toolbox for usage in scientific computing. In scientific computing, when speed matters, Fortran/C/C++ still very much rule and rust won't take their place anytime soon. Julia has a better chance at that, in fact.
- deadbeeves 4y ago
  I'm still developing my opinion of Rust, but * It's too different. This is to be expected because it was never designed to be like C++. For example, if I have an OOP-heavy application, moving it over to Rust is not a matter of fixing up a few ideas here and there like it might be with, say, Java or C#. It calls for a redesign/rewrite. I don't think a memory safe C++ successor would need to be more like Rust than like C++. * The language is not substantially simpler than C++. I find traits to be particularly difficult to reason about and to follow, to the point that I find myself just trying to find the right incantation that will appease the compiler. And that complexity shows up at build time just like it does with C++.
4y ago

pjmlp 4y ago

Rust still needs to prove itself on being a GCC/LLVM alternative, CUDA, SYSCL, HPC and HFT compiler toolchains, MPI, AUTOSAR and MISRA standards, game console SDKs, mobile OS SDKs, .... C++ still has lot of momentum for the upcoming decades, regardless how much we would like to RIIR everything.

adgjlsfhk1 4y ago
I pretty strongly disagree with this. Rust doesn't replace all of C++; it only replaces some. Specifically, there's not a great reason to write a compiler in a language with manual memory management. HPC is also starting to move to higher level alternatives like Julia. Also AUTOSTAR/MISRA are funny to bring up because they are desparate and only semi-successful attempts to bring a semblance of safety to fundamentally unsafe languages. You get all of the safety of them (and more) in Rust with the 2 rules of 1. don't use unsafe. 2. have tests.
- pjmlp 4y ago
  Julia is implemented in C++, and makes use of LLVM, written in C++. Apparently AUTOSAR and MISRA are relevant enough for Rust, that efforts are being made to allow a Rust certification subset as well.
  - adgjlsfhk1 4y ago
    Julia isn't primarily implemented in C++. Most of the implementation is in Julia (68%). About 25% is C/C++, but that could be changed if someone wrote a good enough compiler in a fast enough memory safe language. The rest is in a custom scheme dialect (femptolisp) and is in the process of being replaced by Julia (see JuliaSyntax.jl).
    - pjmlp 4y ago
      Waiting for the LLVM rewrite in Julia.
      - 4y ago

bregma 4y ago

> If C++ doesn’t come up with a good story real soon to deal with memory safety at the language level and deal with the mess of language complexity, it will be relegated to a legacy language. That's exactly the purpose of WG21 SG23, convened for the study of safety and security for C++26 and beyond. You can complain or you can join and influence the future.