HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
duneroadrunner
SaferCPlusPlus
C++2016–2026
duneroadrunner / SaferCPlusPlus

SaferCPlusPlus

A collection of safe data types that are compatible with, and can substitute for, common unsafe native c++ types

Explore on GitHubRead Hacker News discussions
6Distinct people
100Mentions
0Explicit recommenders
426GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A collection of safe data types that are compatible with, and can substitute for, common unsafe native c++ types

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 12:45:45 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year100 dated mentions

Observed mentions: 2016-09-26 19:33:34 UTC to 2026-08-03 12:30:33 UTC.

0102030402016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 21 mentions; 0 submissions, 21 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 40 mentions; 0 submissions, 40 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 14 mentions; 0 submissions, 14 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 18 mentions; 1 submissions, 17 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC21021
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC40040
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC14014
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC18117
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC202
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC110
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC303

What Hacker News says

14 sources
duneroadrunner·Nov 4, 2018
Yeah, with modern C++, you can largely choose to avoid using elements that are prone to undefined behavior. For example, rather than native integers, you could use a compatible integer class that checks for division by zero [1]. Or one that checks for overflow too [2]. The Core Guidelines lifetime checker aims to (eventually) make native pointers and references memory safe via (severe, but not quite as severe as Rust) usage restrictions. And when you need to circumvent the restrictions, you can use an unrestricted smart pointer with run-time checking [3][4]. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus#primitives [2] https://github.com/boostorg/safe_numerics [3] https://github.com/duneroadrunner/SaferCPlusPlus#registered-... [4] https://github.com/duneroadrunner/SaferCPlusPlus#norad-point...
In A Guide to Undefined Behavior in C and C++ (2010)
duneroadrunner·Sep 21, 2018
> This proposal and Rust's guarantees are different. A little different, but only in the sense of being, for the moment, less ambitious (than Rust) about the completeness of the checker's implementation. But I think it substantially demonstrates a straightforward path to achieving the same level of memory safety in C++ as Rust. > For example: > > We do not attempt to address all aliasing cases It seems to me that a main principle behind the design of the Rust language was to eliminate the aliasing issue, by imposing the "mutable references are exclusive" restriction, as a prerequisite to addressing the memory safety issue. And there was an implication (and sometimes more than that) that as long as C++ can't address the aliasing issue it can't address the memory safety issue (like Rust can). I think the key thing that the lifetime checker
Read the rest
demonstrates is that this premise is not (quite) right. You don't need to completely eliminate the aliasing issue to achieve (efficient) memory safety, you just need to address it "enough". And that can be done for C++. Now, whether the complete elimination of the aliasing issue is, apart from the memory safety implications, a virtue that's worth the (flexibility) cost of the "mutable references are exclusive" restriction, is as far as I'm aware, still a matter of opinion. (Given the existence of the RefCell wrapper in Rust, and the ease (if not elegance) of implementing an "anti-RefCell" wrapper in C++, I'm guessing it's mostly a wash.) > > or make concurrency safety guarantees. Programmers are still responsible for eliminating race conditions. Data races are a separate issue, but relative to the (single-threaded) memory safety issue, I think there'd be less controversy that it can be addressed in C++ in vaguely similar fashion to Rust. [1] But both in the case of Rust and the C++ lifetime checker, I don't think that the cost of the imposed (compile-time) restrictions in terms of code/algorithmic flexibility is being adequately acknowledged. For example, say you have a list (or whatever container) of references to (pre-)existing objects. In both cases, the restrictions require that all the objects must (be known to) outlive the list container even if there is a reference to them in the list for only a short time [2]. Imo this is an impractical restriction. In C++, you could use run-time checked pointers[3][4] to alleviate the restriction without sacrificing memory safety [5]. It's not immediately obvious to me that Rust couldn't have such a run-time checked reference as well. But others would be more qualified to make that assessment. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus#multithread... [2] https://github.com/duneroadrunner/misc/blob/master/201/8/Jul... [3] https://github.com/duneroadrunner/SaferCPlusPlus#registered-... [4] https://github.com/duneroadrunner/SaferCPlusPlus#norad-point... [5] https://github.com/duneroadrunner/misc/blob/master/201/8/Jul...
In C++ Lifetime profile v1.0 posted
duneroadrunner·Jun 18, 2018
> Most of the following blog post is written from a game developer’s perspective, but should also apply to other areas ... Video games are a special case where allocations and deallocations are often well scheduled and predictable. For the more general case, using a data type like ivector[1] for the object arrays would provide the desired memory safety. It gives you the flexibility of safely accessing an object via index, iterator or (zero-overhead smart) pointer. Even though it's a vector (like std::vector) its iterators behave like list iterators. That is, after an insertion or removal operation, unlike indexes, they continue to point to the same item (not necessarily the same position) and they only become invalid when the item they point to is removed. In particular, they don't become invalid after a resize/reallocation operation. So
Read the rest
using ivector's iterators instead of index handles would allow you to safely perform insertion/removal operations if necessary. Also, for performance reasons you may sometimes want to temporarily obtain a direct pointer to the item. ivector allows you to obtain a zero-overhead smart pointer to the item that is guaranteed not to become invalid. [2] It does this by disabling "resize" operations on the vector while it exists. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus#vectors [2] https://github.com/duneroadrunner/SaferCPlusPlus#make_xscope...
In Handles are the better pointers
duneroadrunner·Jun 6, 2018
Don't forget about SaferCPlusPlus[1]. Much safer than conventional modern C++. Also (optionally) uses scope lifetimes to prevent use-after-free. (Not yet fully compiler enforced like Rust, but hopefully that'll be coming at some point.) There is a translation helper tool[2] that, at this point, can automatically replace native C array and pointer iterator declarations with macros that make them memory safe (bounds and use-after-free) when compiled in C++ mode. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus/blob/master... [2] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...
In XNU kernel heap overflow due to bad bounds checking in MPTCP
duneroadrunner·Mar 23, 2018
SaferCPlusPlus[1], for example, is a safe subset of C++ that has compatible safe substitutes for C++'s (and therefore C's) unsafe elements. So migrating existing C/C++ code generally just requires replacing variable declarations, not restructuring the code. For C programs, one strategy is to provide a set of macros to be used as replacements for unsafe types in variable declarations. These macros will allow you, with a compile-time directive, to switch between using the original unsafe C elements, or the compatible safe substitutes (which are C++ and require a C++ compiler). The replacement of unsafe C types with the compatible substitute macros can be largely automated, and there is actually a nascent auto-translator[2] in the works. (Well, it's being a bit neglected at the moment :) Custom conventions using macros to improve code qualit
Read the rest
y are not that uncommon in organized C projects. Right? But this one can (optionally, theoretically) deliver complete memory safety. So you might imagine, for example, a linux distribution providing two build versions, where one is a little slower but memory safe. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus [2] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...
In C for All
duneroadrunner·Mar 16, 2018
Yes, documentation and class names are not SaferCPlusPlus' strong points at the moment. Perhaps the easy way to get started is just to use the elements in the "mse::mstd" namespace, like vector, array, string, string_view, etc. which are just safe, compatible implementations of their namesakes in the "std" namespace. As for the pointers, there's a slightly out-of-date article[1] that tries to explain them with examples. But a simple option is to just replace all your raw pointers with "registered" pointers. It's not performance optimal, but it's safe and simple. But yes, better introductory documentation and examples are needed. There is not yet a forum for those picking up SaferCPlusPlus, but for now you can post any questions or suggestions in the issues section[2]. [1] https://www.codeproject.com/Articles/1093894/How-To-Safely-P... [2]
Read the rest
https://github.com/duneroadrunner/SaferCPlusPlus/issues
In A Usable C++ Dialect That Is Safe Against Memory Corruption
duneroadrunner·Mar 16, 2018
> "guaranteed to be safe" (which will most likely require tooling) rather than merely "safer" - and I will be the first one to promote it myself :-) Well I hope so, as SaferCPlusPlus could use a little promotion :) At this point, despite the name, I think the dialect itself is "safe", not just "safer". Potentially unsafe features are relegated to the "mse::us" namespace and are generally only needed for interop with legacy code. Of course there's no way to enforce that a programmer stick to the "dialect"/subset without some tooling. But I think the "rule" for adhering to the SaferCPlusPlus subset is pretty simple and generally intuitive. That is, "any potentially unsafe element of C++ should be avoided". And I think most of us have a pretty good sense of which C++ elements are potentially unsafe. The (few) unintuitive ones might include t
Read the rest
hings like the implicit "this" pointer (which is a native pointer, so it should be avoided). A tool to enforce adherence would be fairly straightforward to write. When there is sufficient demand it will be provided. At the moment an "auto-translation"[1] tool has higher priority. > quite simple: there are only 3 concepts, with 2 of them ('naked' and 'owning'=unique_ptr<>) being already very familiar It's the same with SaferCPlusPlus, but the 3 "concepts" (pointer types) are "reference counting" pointer (=std::shared_ptr<>), "registered pointer" (= safe, unrestricted naked pointer), and "scope" pointer (basically a naked pointer that is restricted to stack allocation (i.e. a "local variable") and can only point to objects guaranteed to outlive it). The Core Guidelines also has three "concepts"/pointer types (shared, unique, and naked). I suspect that some experience will reveal that SaferCPlusPlus has the better set of pointer types. ... Oh wait, you're the author of the article? In which case, I think it would be worth your time to get more familiar with SaferCPlusPlus. Even if just as research for your own dialect. But with some experience, I think ultimately you might be convinced by the SaferCPlusPlus solution. In fact, there's no reason why your (Re)Actors couldn't be implemented on top of SaferCPlusPlus, which would automatically provide the safe "collections" that you need. Don't hesitate to post any questions in the "issues" section[2]. [1] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla... [2] https://github.com/duneroadrunner/SaferCPlusPlus/issues
In A Usable C++ Dialect That Is Safe Against Memory Corruption
duneroadrunner·Mar 15, 2018
If anyone is really interested in this sort of thing, I suggest you take a look at SaferCPlusPlus[1]. It is "A Usable C++ Dialect That Is Safe Against Memory Corruption" (including data races). And it already exists. And I think it's better than this proposed dialect in that most of the (safety) restrictions are enforced without requiring extra tooling, and it's much less restrictive. Most existing C++ code can be converted directly. And the run-time overhead is kept to a minimum. Btw these advantages apply versus the Core Guidelines[2] as well. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus [2] https://github.com/duneroadrunner/SaferCPlusPlus#safercplusp...
In A Usable C++ Dialect That Is Safe Against Memory Corruption
duneroadrunner·Mar 9, 2018
I'm going to dissent on this. While the Core Guidelines "raise the floor" for code safety, I think the may be lowering/hardening the ceiling[1] as well. One problem is that, they impose an (inflexible) standard for function interfaces that is still intrinsically unsafe. For example, they direct you to standardize on std::shared_ptr for objects shared between threads. But this prevents you from using (even) safer smart pointers that, for example, do automatic mutex locking[2]. Presumably the alternatives to a standardized, intrinsically unsafe interface are either a standardized, safe interface, which would require introducing safe alternatives for unsafe elements like std::shared_ptr and raw pointers. Or a more felixible interface standard. For example, making your public functions function templates when necessary. [1] shameless plug: ht
Read the rest
tps://github.com/duneroadrunner/SaferCPlusPlus#safercplusp... [2] https://github.com/duneroadrunner/SaferCPlusPlus#the-problem...
In C++ Core Guidelines
duneroadrunner·Jan 25, 2018
> unless you just don't use pointers or references at all (and refrain from using any library that is not safe which includes large parts of the standard library like all the containers) It may seem far fetched, but it might be more practical than you'd think. The SaferCPlusPlus[1] library provides memory-safe implementations of the most commonly used standard library containers, and pointer types that reflect the lifetimes of their target objects. That is to say, there is a practical subset of C++ that is more closely comparable to safe Rust than is conventional C++. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus
In Unsafe Zig Is Safer Than Unsafe Rust
duneroadrunner·Jan 20, 2018
Two main components of Rust's approach to memory management are i) the imposing/exploiting of scope lifetimes on objects and references, and ii) the restriction that a mutable reference may not co-exist with any other references (to the same object). I suggest that with C++ there is kind of the option of embracing the former, without so much of the latter, to achieve a performance-safety combination that is closer to Rust's than current "modern C++" practices. That's sort of the premise of the SaferCPlusPlus library [1]. If you're a C++ programmer, the barrier to adoption is low. Though without a "borrow checker" or something equivalent, you wouldn't be able to match Rust's performance-safety combination in all cases. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus edit: edited the link
In Building a Website with C++

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.