Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)
Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)
Posted Oct 31, 2023 19:08 UTC (Tue) by kreijack (guest, #43513)In reply to: Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack) by ibukanov
Parent article: Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)
I think that both C and C++ have a so large code base that these fall in "Too big to fail". I am not sure that rewriting a so large codebase will reduce the problems. Because the translation itself will add further problems... for sure.
I am not saying that (e.g.) Rust is weaker than C/C++ or that C/C++ is a "safe" language. But a (aged) C/C++ developer could be capable to write "safe" code easily with a subset of C/C++ than starting to learn Rust.
I think that the Bjarne speech should be read as: the point is not if the (e.g.) Rust is better or worse than C/C++, the point is that you have a) skilled C/C++ developers and b) a large C/C++ codebase that you have to maintain. And this is more simple/reliable using a subset of C/C++ than switching to (e.g) Rust.
In these days I am looking to a C/C++ code for a realtime product. It use a very short subset of C++ (no memory allocation, no string, no exception, no template), and to me it seems simple and enough error proof to the point that the likelihood of an error logic is greater than the likelihood of invalid memory access.
Posted Oct 31, 2023 19:53 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
Similar used to be said, when I was a young developer, about COBOL. In practice, what seems to have happened is that some entities still depend on COBOL, but the majority of the stack we care about (including in places that have legacy COBOL surviving) is written in something more modern, like Java.
This is where Rust's decent FFI story comes into play - if I have a legacy C++ codebase, I can use cxx.rs or perhaps bindgen's C++ support to allow me to incrementally replace parts of the codebase with Rust, just as I work with projects that mix FORTRAN 77 and C, or C++ and Fortran 90 today.
Posted Nov 1, 2023 15:25 UTC (Wed)
by smurf (subscriber, #17840)
[Link]
There is no such subset, and in fact there cannot be. Compilers do not solve the halting problem, thus you need language extensions to tell it about your intent. Without these, they cannot check that your code is "safe".
Rust has mutability and object lifetime syntax, which works (for the most part).
You guess which language has problems with safety.
Stroustrup's approach is not going to fix this. Profiles are a nice idea but how the heck should the compiler know that your library needs exclusive access and to, and/or will eventually deallocate, an object you pass in, if you don't declare that fact? How should it know that returning a pointer/reference/whatever to some member of a struct (and thus the caller's use of it) is safe, if you don't have a way to declare that in the requisite function's interface? and so on.
The fact that he doesn't seem to have concrete ideas about the semantics of these profiles doesn't help.
Posted Nov 2, 2023 19:06 UTC (Thu)
by khim (subscriber, #9252)
[Link] (1 responses)
You are in luck, then. Rust handles logic errors just fine. In fact affine type system (which Rust hides behind ownership and borrow checker) was invented many decades ago precisely to handle logic errors and not to handle invalid memory accesses. The epiphany that converted Rust from yet-another-experimental-language into something-that-may-actually-replace-C/C++ was accidental observation: if you have type system which may prevent data races and ensure that you couldn't use hardware improperly then… you may as well use it to handle memory allocations, too! And drop garbage collector from your language. It's both hilarious and sad that this, pretty obvious, step took more than quarter-century, but in hindsight it's pretty obvious, isn't it? More rigorous and strict tool should be able to perform duties of more limited and less powerful tool, isn't it? I guess the fake “fact” that “safe memory management equals garbage collection” was established in mids of developer's community so firmly than no one was even thinking about whether alternate solutions are possible. That's why this, incredibly important, step had to wait for the moment when theorists met practitioners.
Posted Nov 3, 2023 11:22 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
There's an important thing here that pushes against the desire for any language to be stable in the long run (and it remains to be seen if the Rust "editions" system is able to mitigate this); there's always a lot of research ongoing into programming language theory, much of which ends up concluding "yep, we can do this, but it's not practical".
As a result, you either need a mechanism to adopt the things that researchers show are practical and useful, or you stagnate at the state of the art when your language was first designed (at best).
Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)
Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)
Python sidesteps the issue by reference-counting the world (and accepts the resulting impact on performance and memory footprint).
C++ ignores the problem and simply asks the programmer to not write unsafe or UBish code, or else.
> and to me it seems simple and enough error proof to the point that the likelihood of an error logic is greater than the likelihood of invalid memory access.
Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)
Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)