|
|
|
|
|
|
by adrianratnapala
3120 days ago
|
|
|
> though it will break if you need the same object used across two disjoint subtrees of the calll tree Yes, while I prefer to use plain values or unique_ptrs when I can, I will use C++ references (or plain pointers) in this sort of situation. Basically in C++ I think an of old-style pointers/refs as Rust-like "borrowed" references. This is an example of how the Rust safety model is really about compiler enforcement of good practices from C and C++ (as opposed to, say, GC which is a distinct practice). I appreciate what Rust is doing, but it is also true that good coding conventions in C++ will get you 90% of the way there. |
|
|
For those that need it, SaferCPlusPlus conventions will get you even further.
> Basically in C++ I think an of old-style pointers/refs as Rust-like "borrowed" references.
They key safety feature of Rust references is that they have "scope lifetime" and their target is guaranteed to be alive for the duration of that scope lifetime. You can use SaferCPlusPlus' "scope pointers"[1] to achieve this in C++.
Scope pointers can be explicitly converted to raw pointers, so they can be used with existing "legacy" functions. But you get even more benefit when you change your function interfaces to support scope pointers directly[2]. For example, it would prevent the function from (inappropriately) putting a copy of the scope pointer into "long term storage" (like Rust does).
[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus#scope-point...
[2] https://github.com/duneroadrunner/SaferCPlusPlus#safely-pass...