If I can autoport my C++ to Rust, and the port is confirmed identical, and the Rust is confirmed safe, can't I use that to reason about the safety of my C++? Is safe C++ just a matter of proving it has a safe Rust equivalent?
> our reference-counted translation model, where every variable is pessimistically wrapped inside a Rc<RefCell<T>> type, checks that would usually execute at compile-time are shifted to run time, degrading performance.
If the concern is memory safety, I'd invite comparison with migration to the scpptool-enforced memory-safe subset of C++ [1]. If your C++ code is "idiomatic modern" C++, then the changes required to conform to the safe subset (in an idiomatic way) are often modest, and as demonstrated in the link, often something an LLM can handle for you. Since the safe subset does not impose a universal restriction on mutable aliasing the way Rust does, it doesn't require wrapping everything in `RefCell<>`s or anything like that (unless the objects in question are being shared between threads).
If your C++ code is more "legacy" than "modern", the migration is generally still straightforward, but will often involve additional run-time overhead, like it does with this cpp2rust, but to a lesser degree I think. Objects allocated on the stack can (safely) remain allocated on the stack even when they are the target of pointers. And still, no `RefCell<>` equivalents are required for objects that aren't shared between threads.
Interesting, but unpractical. As I know there is no way to perform automatic translation from one programming language to another without producing code which looks terrible in the destination language.
In this particular example I see no real safety benefits. If the source program is buggy, the result translated program willcrash at runtime, but if it's (mostly) bug-free and UB-free, such translation gives no benefits.
12 comments
[ 4.3 ms ] story [ 30.5 ms ] threadkeep in mind that rust:
- does not prevent logic errors
- does not prevent stack overflows
- does not prevent out of memory errors
- does not prevent bitflips caused by faulty hardware or cosmic rays
- does not prevent memory leaks
- does not prevent unrecoverable errors (panics)
- does not prevent memory safety related issues in an unsafe context
> our reference-counted translation model, where every variable is pessimistically wrapped inside a Rc<RefCell<T>> type, checks that would usually execute at compile-time are shifted to run time, degrading performance.
If your C++ code is more "legacy" than "modern", the migration is generally still straightforward, but will often involve additional run-time overhead, like it does with this cpp2rust, but to a lesser degree I think. Objects allocated on the stack can (safely) remain allocated on the stack even when they are the target of pointers. And still, no `RefCell<>` equivalents are required for objects that aren't shared between threads.
[1] https://github.com/duneroadrunner/scpptool/blob/master/READM...
In this particular example I see no real safety benefits. If the source program is buggy, the result translated program willcrash at runtime, but if it's (mostly) bug-free and UB-free, such translation gives no benefits.
I'm not yet convinced that the issue of C's unsafety is better solved by translating it to Rust rather than using Fil-C [2].
https://pldi26.sigplan.org/program/program-pldi-2026/
https://fil-c.org/