Repo on GitLab

Dec 4, 2023: New release is out. See the blog entry for that day for more.

C++ to Rust Assisted Migration

C++ to Rust Assisted Migration (CRAM) semi-automatically migrates well-designed, general-purpose C++ code into the Rust programming language. The motivation is to benefit from Rust's safe programming abstractions, especially its memory access interface, enforced via an ownership model. The end-goal is to reduce program crashes, hangs, and security vulnerabilities caused by low-level memory management performed by the programmer, a common risk associated with legacy languages. The migrated source code will be human-readable and ready for further development in Rust.

Our philosophy is that Rust's programming abstractions merely enforce what a safety-conscious C++ programmer should be doing anyway, even if the C++ language does not require it. Our migration therefore first refactors the given C++ program to a new C++ program, attempting to enforce many of the Rust programming abstractions at the C++ level. This prepares and facilitates, possibly even enables, the actual translation into Rust. Our migration then continues by identifying computational patterns in the C++ program and translating them into Rust code templates, supported by a library for code pattern translation.


The following video illustrates the usage of CRAM to refactor a C++ code base towards a Rust implementation of the same program, and then ultimately translate the refactored C++ to an idiomatic Rust implementation. In this demo, CRAM is embedded into the VS Code development platform, which is perhaps the most customer-friendly way to use CRAM, but not the only way. The video shows the capabilities of CRAM at the time the video was taken. For up-to-date information on the capabilities, consult our blog.


You are welcome to contact the current CRAM developers by email.


This material is based upon work supported by DARPA under Contracts no. HR001122C0025 and HR001123C0079. Any opinions, findings and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of DARPA.