4 ms·

Have to mention SaferCPlusPlus[1] here - basically a memory-safe subset of C++ with (fairly) low migration cost. For example, here[2] is an open source png enco

• bluejekyll 9y ago
  I keep seeing people say C++ can be "safe", but yet to see something with as much safety as Rust. So, question, is this subset you speak of as safe as Rust?
  • duneroadrunner 9y ago
    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. The implementation of SaferCPlusPlus as a language/dialect is not yet complete. For example, there is not yet a proper compile-time "enforcement" tool to verify that your code is actually free from unsafe elements. But as a programmer, you basically know what those potentially unsafe elements are, and the SaferCPlusPlus library already makes it practical to write C++ code that avoids the vast majority of them. That said, I would say that, at the moment, SaferCPlusPlus is not a direct alternative to Rust. If you have the resources to do a rewrite of your project in Rust and memory safety is paramount, then that's probably the way to go. On the other hand, if you need a more expedient way to address code safety or have some other issue with using Rust, SaferCPlusPlus may be a more attractive choice. https://github.com/duneroadrunner/SaferCPlusPlus#safercplusplus-versus-rust https://github.com/duneroadrunner/SaferCPlusPlus#safercplusp...
    • bluejekyll 9y ago
      Thanks for the link and the detailed explanation. This confuses me a bit: > SaferCPlusPlus does not restrict the number and type of references to an object that can exist at one time (i.e. the exclusivity of mutable references) and > SaferCPlusPlus .. deals with this issue by having the pointer/reference itself "know" if its target dynamic object is still valid. It sounds like this happens at runtime (reference counting?), as opposed to compile time. Do I understand that correctly? Also, I see that there is the `access requester` type, are there any facilities like Send/Sync in Rust which guard against data races at compile time or runtime? Thanks in advance!
      • duneroadrunner 9y ago
        Well, the "scope" pointers, which roughly correspond to Rust's "non-mut" (i.e. non-retargetable) references and are generally the most commonly used pointer/reference type, don't have any run-time overhead. By their nature, as long as they exist, so does their target. You don't need a sophisticated borrow checker to ensure it. "Mut" (i.e. retargetable) references, on the other hand, do require a borrow checker to ensure, at compile-time, that their target will outlive them. Since SaferCPlusPlus does not have a borrow checker (yet), you'd have to use "registered" pointers, which do have run-time overhead. But in practice, retargetable references are generally much less common than non-retargetable ones (particularly in inner loops), so there tends not to be much effect on performance. SaferCPlusPlus does not yet have an exact analogy to Send/Sync. But as I understand it, those are basically just indicators that say "Trust me, this object is safe to send to / share with other threads." without any verification of the proclaimed safety. At the moment, SaferCPlusPlus does something functionally similar by providing the "TAsyncSharedObjectThatYouAreSureHasNoUnprotectedMutablesReadWriteAccessRequester" which basically allows you to make the same claim about the safe shareability of the object. (And has an unwieldy name to remind you of the seriousness of the claim.) Basically the rule of thumb is "Don't share any object that contains pointers/references/iterators (or is declared "mutable" in C++) or has any (non-static) member functions that return pointers/references/iterators." Rust and SaferCPlusPlus maybe take different positions on whether sharing objects between threads should be encouraged with abandon, or done prudently and only as necessary.