SaferCPlusPlus

> 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] shame

You mean how it's implemented? Umm, well it's been a while, but basically an ipointer is a proxy for an iterator that is stored internally by the msevector. These "internally stored" iterators are updated when necessary. For example, when insert() or erase() is called. One nice thing about it is that it roughly conforms to the principle of "only pay for what you use". That is, the run-time cost is roughly proportional to the number of ipointers you have and the frequency of operations that modify the size of the vector. One caveat is that this mechanism is not thread safe. But whenever you need to share the vector among threads, you can swap it with a vector that is safe to share[1]. And for those that are into memory safety, there is also a memory-safe vector[2] that supports ipointers. Is this the sort of explanation you're looking for?

The problem is that, while in many ways an improvement over traditional coding practice, the subset of C++ associated with the Core Guidelines (GSL stands for "(Core) Guidelines Support Library") has turned out to be a dead-end when it comes to memory safety. In fact it formalizes the depenedency on intrinsically unsafe elements like native pointers, std::shared_ptr, etc. I mean, with "regular" C++ you're not actually obligated to use those intrinsically unsafe elements. With the Core Guidelines you are. SaferCPlusPlus[1] is an alternative subset of C++ that doesn't have that same problem. It achieves memory safety by simply excluding the intrinsically unsafe elements and providing memory-safe alternatives. > All compile time checks. Not quite in reality. One small issue with the GSL, for example, is that its not_null pointer class does a

It's arguably even a little bit nicer in SaferCPlusPlus[1]: template<typename TVectorPointer> void write_foo(TVectorPointer vec_ptr) { (*vec_ptr)[3] += 1; } template<typename TVectorPointer> auto read_foo(TVectorPointer vec_ptr) { return (*vec_ptr)[7]; } template<typename TVectorAccessRequester> void use_shared_vector(TVectorAccessRequester vec_ar) { { // obtain a non-const pointer to the vector from the "access requester" // blocking if necessary auto wl_ptr = vec_ar.writelock_ptr(); write_foo(wl_ptr); // the pointer owns a lock on the vector so as long as the pointer // exists it is safe and valid to use } // obtaining and using a const pointer to the vector auto res1 = read

> basically a nicer C++ with the obvious foot guns removed For those stuck with C++, you're not out of luck in terms of safe and easy sharing between threads. The SaferCPlusPlus library provides "access requesters" that provide functionality and (data race) safety similar to Arc<T>. Unfortunately the documentation[1] is "in transition" at the moment and does not currently refer to the very latest version. But the main difference is that the latest version implements something akin to rust's "sync" trait to help prevent you from attempting to share inappropriate data types. Again, documentation is a work in progress, but if you're interested you can check out an example that demonstrates an array being safely modified simultaneously from multiple threads[2]. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus#asynchronou..

First let me say that I'm not familiar with Nim. But I understand that it compiles/transpiles to C/C++. And it sounds like they're now trying to move away from dependency on the GC. In that case, might I suggest they consider switching the transpile target to SaferCPlusPlus[1]. It might make things easier as it already addresses the "efficient memory-safety via scope lifetimes without a borrow-checker" issue. And also the (data race) safe sharing of objects between threads. (Note that the documentation is currently rather out-of-date, and a major update is coming.) [1] shameles plug: https://github.com/duneroadrunner/SaferCPlusPlus

> For one thing, the "this" pointer problem is pretty much unsolvable in C++. Well, you could just avoid/prohibit the explicit and implicit use of the "this" pointer. I.e. prohibit non-static member functions[1], right? [1] https://github.com/duneroadrunner/SaferCPlusPlus#practical-l...

> On the other hand, it probably is less effort to rewrite PolarSSL in Rust than doing that proof. It's probably even less effort to convert to SaferCPlusPlus[1] (essentially a memory-safe subset of C++). There's even an tool[2] (under construction, but functional) to do a lot of the conversion for you. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus [2] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

While "just enforcing `make_shared`" wouldn't solve all the memory safety issues, it actually can be somewhat practical to "just avoid using any (or most) C++ elements that can access invalid (or uninitialized) memory", instead using the safe, compatible substitutes in the SaferCPlusPlus[1] library. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

> "- Span For when you want to take an array or a vector." > How's this different from taking a pair of iterators? Safety and (a little) convenience. If your function takes a pair of iterators, there's no way to ensure (at compile-time anyway) that both iterators are even pointing into the same array/vector. Also, spans can ensure, with bounds-checking, that only elements within a specified sub-range can be accessed. Such bounds-enforcement is particularly important in cases like, for example, SaferCPlusPlus' "TRASectionSplitter", which is a data type that allows you to partition an array/vector/whatever into subsections that can each be safely accessed/modified concurrently from different threads. ("TRASectionSplitter" is not yet documented, but for those interested, example code can be found here[1].) [1] shameless plug: https://github.

> - Mutex From their "Devguide": Clients of Mutex must obey these rules: 1. Each time a thread acquires a Mutex it must later release it. 2. A thread may not attempt to release a Mutex unless it holds it. 3. A thread may not attempt to acquire an exclusive lock on a Mutex it already holds. For basic sharing of resources between threads, using "access requesters"[1] can be safer and more convenient as they automatically take care of these rules for you. And if you need to use the mutex directly, the SaferCPlusPlus library provides a "recursive_shared_timed_mutex"[2] (the one missing from the standard library), which allows a thread to hold multiple ("read" and/or "write") locks at the same time (relieving the "self-deadlock" issue). The mutex isn't documented, but it functions just as its name suggests. [1] shameless plug: https://github.c

SaferCPlusPlus[1] is the library that's probably closer to Rust "in spirit and intent". And more importantly, safety effectiveness. And it does address the data race issue. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

You can use the SaferCPlusPlus library[1] to get closer to "java safety". C++ compile times are a problem. Apparently there is a C++ interpreter[2]. Anyone have any experience with it? [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus [2] https://root.cern.ch/cling

Yeah, I don't know if there's ever going to be a portable way to enforceably "disallow" the sharing of state between threads in C++. For straightforward cases, the SaferCPlusPlus library provides an easy way to "wrap" any object so that access from different threads is safely controlled[1]. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus#asynchronou...

Technically, you would need to unambiguously define what you mean by "safe" and "Rust", but in the way that I think you mean it, the answer is essentially yes. "SaferCPlusPlus" does not refer to "modern" C++ programming practices that can help avoid many traditional classes of bugs. It, in theory, refers to the avoidance/prohibition of any C++ element that can access unallocated/deallocated or uninitialized memory. That means for example, no native pointers (including the implicit "this" pointer in member functions), references, arrays, unions, etc.. It also means no unsafe standard library elements like std::vector, std::array, std::shared_ptr, std::unique_ptr, etc.. In order to make this practical, there is a SaferCPlusPlus library that provides largely compatible (memory) safe substitutes for the most commonly used of these elements. T