Cpp2Rust: Translates C++ to safe Rust automatically
signa11
47 points
12 comments
July 10, 2026
Related Discussions
Found 5 related stories in 52.0ms across 5,215 title embeddings via pgvector HNSW
- Canonical backs new project to translate large C codebases into safe Rust datakan · 38 pts · August 20, 2026 · 67% similar
- Scaling Memory Safety: AI-Assisted Rewrites of C/C++ Dependencies to Rust afdbcreid · 15 pts · August 24, 2026 · 66% similar
- GPU Offload in Rust: Portable, Safe, and Fast linggen · 185 pts · August 17, 2026 · 53% similar
- Rust 1.98.0 thesuperbigfrog · 17 pts · August 20, 2026 · 53% similar
- How Our Rust-to-Zig Rewrite Is Going jorangreef · 467 pts · July 16, 2026 · 52% similar
Discussion Highlights (7 comments)
z_open
Why does the example not show an example of unsafe C++?
migueldeicaza
codex "/goal port this codebase from c++ to rust"
logicchop
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?
IshKebab
Yeah the readme definitely needs some non-trivial examples. How does this handle raw pointers? Operator overloading? Inheritance?
crnakfls
> Notable unsupported constructs include: union, volatile, goto, exceptions, bitfields, placement new, user-defined copy/move constructors, dynamic_cast, const_cast, base classes with fields or non-virtual methods, multiple inheritance, and multi-threaded code.
dmitrygr
The original paper quoth: > 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.
safercplusplus
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. [1] https://github.com/duneroadrunner/scpptool/blob/master/READM...