11–20 of 22 posts
> 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.
> our reference-counted translation model, where every variable is pessimistically wrapped inside a Rc> 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.
codex "/goal port this codebase from c++ to rust"
> 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.
The readme is rather slim on C++ versions.
> 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.
Lol, “user defined copy/move constructors” That’s actually so many types that would define this
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].