duneroadrunner

13 ms·

61.
by duneroadrunner 9y ago
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&qu
62.
by duneroadrunner 9y ago
> "- 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 en
63.
by duneroadrunner 9y ago
> - 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 a
64.
by duneroadrunner 9y ago
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&#x
65.
by duneroadrunner 9y ago
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
66.
by duneroadrunner 9y ago
One case the author left out was translation to "idiomatic" higher level language, which involves identifying abstractions that are intrinsically present, but where never explicitly expressed, in the original code. For example I&#
67.
by duneroadrunner 9y ago
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 "wra
68.
by duneroadrunner 9y ago
Sorry, I don't think I was thinking very clearly for the last part. I think you're right, the missing Send/Sync functionality is one of the areas where SaferCPlusPlus is still lacking.
69.
by 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
70.
by 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&qu
71.
by duneroadrunner 9y ago
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 encoder/decoder that was ensured to be free from buffer overflow vulnerabilitie
72.
by duneroadrunner 9y ago
> I think there really needs to be a "Safe STL" in addition to "Performant STL" that performs range checks. SaferCPlusPlus[1] provides compatible, memory-safe versions of the most commonly used STL containers. (The co
73.
by duneroadrunner 9y ago
I think all your points are probably right (and insightful). But I think in this case the (immediate) goal isn't really popular adoption of this solution by existing C (or maybe even C++) programmers. In part, it is simply a practical,
74.
by duneroadrunner 9y ago
I can't say for certain why none of the "safer C"s have caught on, but I can say that they all have significant compromises and/or impracticalities. Often, performance cost is one of them. Today though, you can use the s
75.
by duneroadrunner 9y ago
Obligatory shameless SaferCPlusPlus[1] plug: It is now practical to eliminate the use of unsafe C/C++ elements (like pointers and iterators) by replacing them with safe, compatible substitutes. Using the SaferCPlusPlus library, your ex
76.
by duneroadrunner 9y ago
It's still in early development, but there is a tool[1] that automatically converts potentially unsafe C/C++ code to be memory-safe. If the problem is C/C++ programmers that write unsafe code, rather than trying to change the
77.
by duneroadrunner 9y ago
> Switching languages requires a full rewrite ... It's not ready for use in the wild, but I'll just mention that some good progress is being made on a "C to SaferCPlusPlus[1]" auto-translation assistant. (SaferCPlusPl
78.
by duneroadrunner 9y ago
> That said, the expected win for Rust over C(++) in practice is that you can be more "reckless", ... I'm glad to see somebody articulate this observation. SaferCPlusPlus[1] is meant to, in part, bring this benefit to exis
79.
by duneroadrunner 9y ago
And don't forget the llvm (and gcc) sanitizers[1] and SaferCPlusPlus[2] (essentially a memory safe subset of C++), which are more modern and have arguably better overall combinations of performance/safety/compatibility/p
80.
by duneroadrunner 9y ago
Thanks. I'll take all the git/github advice I can get. :)
81.
by duneroadrunner 9y ago
If any of the developers are reading this, converting the existing C code to SaferCPlusPlus[1] (a memory safe subset of C++) is probably a more expedient solution (if that's what they're looking for). (And speaking of contributing
82.
by duneroadrunner 10y ago
> when you have a lock held but then attempt to take a lock again in some control path (perhaps through a recursive or deep call stack, or, in your case, calling another member function The standard library provides std::recursive_mutex
83.
by duneroadrunner 10y ago
When data races are the concern, SaferCPlusPlus provides nice data types for safely sharing objects asynchronously[1]. Basically, glorified shared_ptrs that automatically handle all the necessary locking (and blocking). [1] shameless plug:
84.
by duneroadrunner 10y ago
> I just don't think there's a viable alternative Fyi, when safety is important and C++ is the only viable alternative, there's SaferCPlusPlus[1]. And wrt new C++17 features, I'll just point out that the SaferCPlusPlu
85.
by duneroadrunner 10y ago
I haven't read the book. What's the gist of the recommendations for addressing those issues? SaferCPlusPlus addresses the signed/unsigned issue by providing compatible substitutes[1] for "int" and "size_t"
86.
by duneroadrunner 10y ago
> This one is totally obvious but has a stunning number of ways you can fail to adhere to it, some of which look reasonable at first blush If memory safety is actually important to you, there's now an actual practical solution: Safe
87.
by duneroadrunner 10y ago
That's one of the arguments for SaferCPlusPlus[1]. It's a (high performance) option for retrofitting memory safety to existing C/C++ codebases. It requires (straightforward) modifications to the existing code, but involves mu
88.
by duneroadrunner 10y ago
Not technically a separate language, SaferCPlusPlus[1] is a memory safe dialect/subset of C++. As far as I know, it is by far the highest performance[2] solution currently available for addressing memory safety in C/C++ code (asid
89.
by duneroadrunner 10y ago
> or b) just use Rust to extend and piecemeal replace old apps (since it supports linking to C and/or C++ libs). Yes, Rust's FFI support is nice, but rewriting piecemeal is still rewriting. (And retesting.) It should be faster
90.
by duneroadrunner 10y ago
Yes. But there's also substantial cost in abandoning existing C/C++ codebases and rewriting them from scratch. Since the advances of C++11, something like SaferCPlusPlus[1] (a memory safe dialect/subset of C++) might be a mor

More ›