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

18 sources
safercplusplus·Nov 7, 2019
And also one less thing to transfer to the heads of anyone else that might need/want to understand the code. (Often the author him or herself at some point in the future, right?) Though equivalent facilities are available in C++ [1][2] (and can now/soon be enforced[3]). [1] https://github.com/duneroadrunner/SaferCPlusPlus/blob/master... [2] https://github.com/duneroadrunner/SaferCPlusPlus/blob/master... [3] https://github.com/duneroadrunner/scpptool
In Comparing Parallel Rust and C++
safercplusplus·Apr 23, 2019
Others disagree, but I suggest that someone could make such a linter. As others point out, the Core Guidelines "lifetime profile checker"[1] is designed to be an advanced static analyzer that restricts how many C++ elements can be used. It's not finished yet, and the current version is not designed to achieve complete memory safety (and doesn't address data race safety). Whether or not subsequent versions could match the full safety enforcement of Rust's compiler seems to be a matter of some debate. But there is an alternative/complementary approach, which is to simply avoid potentially unsafe C++ elements, like pointers/references, arrays, std::string_views, std::threads, etc., substituting them with safe, largely compatible replacements[2]. This approach has the benefit that an associated safety-enforcing "linter" would not impose the s
Read the rest
ame kinds of "severe" usage restrictions that the lifetime profile checker (or, say, the Rust compiler) does. [1] https://devblogs.microsoft.com/cppblog/lifetime-profile-upda... [2] https://github.com/duneroadrunner/SaferCPlusPlus edit: grammar
In Modern C++ Won't Save Us
safercplusplus·Apr 16, 2019
> like a weak pointer that work with unique_ptr, but I do not think it is possible to do this while preserving zero overhead implementation I think the type of pointer you're asking for basically does exist. First, you want to distinguish the cases when you want a "full featured" weak pointer that can gracefully handle the destruction of its target object [1] (rarely the case), or you just want a non-owning pointer that detects when the prorammer screws up and lets the target object be destroyed prematurely [2]. The latter is essentially just a non-owning reference counting pointer. The optimizer should be able to discard matching increments and decrements of the reference counter in many cases. > This will have overhead, but it could be worth it for the security gains. The performance cost of avoiding "unsafe" C++ elements is measurable,
Read the rest
but reasonably modest [3]. [1] https://github.com/duneroadrunner/SaferCPlusPlus#registered-... [2] https://github.com/duneroadrunner/SaferCPlusPlus#norad-point... [3] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...
In Virtually Unlimited Memory: Escaping the Chrome Sandbox
duneroadrunner·Apr 4, 2019
> Cone actually does support Rust-like, lifetime-constrained borrowed references Ah, so kind of a super-set of Rust functionality. Presumably these would require a "borrow checker" or equivalent? Is that already implemented? So how do you address the safety of, say, taking a reference to an element in a (resizable) vector? Rust's "exclusivity of mutable references" restriction intrinsically makes the vector immutable while the borrowed reference exists, but do I understand that Cone doesn't have that restriction? The "C++ lifetime profile checker", on the other hand, makes the vector non-resizable (but leaves the data mutable). > A key requirement I have placed on references (vs. pointers) is that you can always de-reference them and get a valid value SaferCPlusPlus provides both a pointer that throws an exception if you attempt an invali
Read the rest
d memory access (though it could just as easily return an optional<>, and you can always query if the target is valid), and one that terminates the program if its target is ever deallocated prematurely (and thus (technically) satisfies your criteria). (The latter has less/minimal overhead.) > A Cone programmer would need to use raw pointers to throw off the shackles of lifetime constraints Or reference counting pointers or GC, right? The features needed to implement the pointers I mentioned is either support for calling a destructor on move operations or the ability to make an object non-movable, and, support for copy constructors or the ability to make an object uncopyable. Does/could your language support some combination of those features? I explain the reason the pointers are important in an article called "Implications of the Core Guidelines lifetime checker restrictions" [1]. Specifically, I give an example of reasonable C++ code [2] that historically had no corresponding efficient implementation in Safe Rust. (I think it's still the case, but I haven't fully investigated the implications of Rust's new "pinning" feature.) It can, however, be implemented in a memory safe way using the SaferCPlusPlus pointers in question [3]. Basically the example just temporarily inserts a reference to a (stack allocated) local variable into a list (or whatever dynamic container), given that the local variable does not outlive the container. > especially given that borrowed references and raw pointers are both able to point inside an allocated object SaferCPlusPlus has the equivalent of "borrowed references"[4] (though even more restricted until C++'s "borrow checker" (the aforementioned "lifetime profile checker") is completed), and they can safely point "inside" (allocated) objects. Note that the second safe pointer type (the one that potentially terminates the program), is a "strong" pointer, and there is a simple mechanism for obtaining a "borrowed reference" from a strong pointer [5]. And from there, a simple mechanism for obtaining a reference to an (interior?) member [6]. The other pointer (the one that potentially throws an exception) would be considered a "weak" pointer, and you cannot obtain a "borrowed reference" directly from a weak pointer. But often, the weak pointer is used to target an object that can yield a borrowed reference (like a strong pointer, for example), or a borrowed reference directly. > all the best with getting others to learn about and adopt your language. You too :) I can see the appeal of this sort of clean, flexible language. But in the case of SaferCPlusPlus the goal is not necessarily (just) for programmers to adopt it. In part it's maybe a demonstration (to language designers such as yourself :) of a set of language elements that use run-time safety enforcement mechanisms but are a little more flexible than (and might be a good / (unintuitively) needed complement to) their counterparts that rely on strictly compile-time safety enforcement. Oh and if you do get around to checking out SaferCPlusPlus in more depth, apologies for the inadequate documentation in advance. Feel free to post any questions you might have. :) [1] https://github.com/duneroadrunner/misc/blob/master/201/8/Jul... [2] https://github.com/duneroadrunner/misc/blob/master/201/8/Jul... [3] https://github.com/duneroadrunner/misc/blob/54204445bc099987... [4] https://github.com/duneroadrunner/SaferCPlusPlus#txscopeitem... [5] https://github.com/duneroadrunner/SaferCPlusPlus#make_xscope... [6] https://github.com/duneroadrunner/SaferCPlusPlus#make_pointe...
In Cone Programming Langauge
duneroadrunner·Apr 3, 2019
If maximum (or just more) flexibility wrt memory safety is the goal, I might suggest the author take a look at SaferCPlusPlus. In particular, it supports memory safe pointer/references[1][2] that can target objects associated with different allocators (including stack allocated objects) without, as the author desires, imposing the "sometimes confining" restrictions that Rust does. And in terms of data race safety, it allows you to hold "read-lock" and "write-lock" pointer/references simultaneously in the same thread [3], which adds a little extra functionality (and maybe convenience). [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus#registered-... [2] https://github.com/duneroadrunner/SaferCPlusPlus#norad-point... [3] https://github.com/duneroadrunner/SaferCPlusPlus#tasyncshare...
In Cone Programming Langauge
duneroadrunner·Mar 19, 2019
> "Unknown" ranges from 49% to 76%. Yeah, this is interesting. They're saying they can't determine whether a pointer targets an array buffer or not? Perhaps they might want to take a look at the (long neglected) "C to SaferCPlusPlus" translator[1] which can do this. (It was an unexpectedly taxing undertaking though.) It converts C arrays and allocated buffers used as arrays into memory safe implementations of std::array<>s and std::vector<>s, so failure to properly identify them would generally result in output code that wouldn't compile. The examples they give of problematic code in the paper: void f(int* a) { *(int**)a = a; } and f1(((int*) 0x8f8000)); don't strike me as the kind you would often encounter in real-world code. > The syntax they use is rather clunky The output code of the "C to SaferCPlusPlus" transla
Read the rest
tor replaces the types and declarations with macros[2] that can be redefined with a compile-time directive to either use the safe C++ implementation, or revert to the original unsafe native C implementation. The argument being that using macros instead of custom syntax makes the source code more versatile. And existing C programmers already "get" macros. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla... [2] https://github.com/duneroadrunner/SaferCPlusPlus/blob/master...
In Achieving Safety Incrementally with Checked C
duneroadrunner·Mar 15, 2019
Yes, It's hard to deny the intuitive appeal, but what's notably missing from that blog post, and seemingly any other article about it, is a consideration of the cost/downsides of universal imposition of the "exclusivity of mutable references" restriction. Rust provides the RefCell wrapper to essentially circumvent the restriction on demand, but i) that also essentially circumvents the "invariant protection" benefits of the policy, and ii) you can just as easily use an equivalent wrapper[1] in C++ to impose the same restriction. At which point the difference between Rust and C++ just kind of becomes which policy do you want to be the zero-overhead default. I mean you could imagine a hypothetical future scenario where it is demonstrated that the optimizers are good enough to essentially eliminate the run-time cost of RefCell wrappers, and a
Read the rest
lot of Rust programmers just start wrapping everything with RefCells by default. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus#exclusive-w...
In Why I rewrote the mesh generator of Dust3D from Rust to C++
duneroadrunner·Mar 15, 2019
Rust's usability is advancing, but I'll note that so are C++'s memory safety facilities. Arguably, modern C++ programming is becoming intrinsically more safe than more traditional coding styles (though arguably the use of string_views and spans outside of function parameters is a step backwards), but progress is also being made on the lifetime profile checker (C++'s borrow checker analogue), and there are libraries[1] that allow you avoid potentially unsafe C++ elements, to the degree that (memory and data race) safety is a priority. At present, C++ is significantly lacking in safety enforcement tooling and "community enthusiasm" for memory safety compared to Rust. But to me, it is not obvious that that will be the case indefinitely. It's even plausible that Rust and C++ will sufficiently converge in flexibility and safety that at some po
Read the rest
int automated translation between the two languages will be a thing. At the moment, I think the main relevant difference in fundamental (as opposed to not-yet-available tooling or whatever) capability between the two languages is Rust's lack of support for move constructors/destructors. I think it prevents the safe, efficient, unintrusive, robust implementation of a small but significant set of algorithms / data structures. But I guess my point is that I think that C++, and its existing codebases, are not necessarily condemned indefinitely to be memory unsafe in the way they have been historically. And that could be a factor that contributes to the justification of deciding to continue to use C++ in some cases. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus
In Why I rewrote the mesh generator of Dust3D from Rust to C++
duneroadrunner·Mar 7, 2019
They are working on it. The analogue to the borrow checker in C++ is called the "lifetime profile checker" and (an incomplete version) is included in MS Visual C++, but last time I checked (in January) it seemed to still have too many false positives to be practical. In the mean time, I think "the minimum necessary changes" to achieve memory and data race safety is to replace all your unsafe C++ elements (pointers, arrays, vectors, string_views, etc.) with compatible substitutes from the SaferCPlusPlus library [1]. You don't even need to replace them all at once. You can replace them incrementally and your code will continue to compile and run throughout the process. And where needed, maintain maximal performance as well [2]. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus [2] https://github.com/duneroadrunner/SaferCP
Read the rest
lusPlus-BenchmarksG...
In Serious Chrome zero-day
duneroadrunner·Mar 7, 2019
I suggest that the most expedient (cheapest) language to migrate the existing code base to would be a memory safe subset of C++ [1]. In practice most of the safety benefit could be obtained from a just a partial migration. Specifically, just banning raw pointers/views/spans and non-bounds-checked arrays and vectors. From a quick glance at the code in the (quite small) patch diff, the code in question includes: DOMArrayBuffer* result = DOMArrayBuffer::Create(raw_data_->ToArrayBuffer()); ... raw_data_.reset(); ... return result; I'd imagine the effort/time/money it would take to replace those raw pointers with memory safe substitutes [2][3][4] (and enforce the ban going forward) would be relatively modest. Performance shouldn't be an issue [5]. [1] shameless plug: https://github.com/duneroadrunner
Read the rest
/SaferCPlusPlus [2] https://github.com/duneroadrunner/SaferCPlusPlus#registered-... [3] https://github.com/duneroadrunner/SaferCPlusPlus#norad-point... [4] https://github.com/duneroadrunner/SaferCPlusPlus#scope-point... [5] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...
In Serious Chrome zero-day

Showing the 15 most recent of 18 sources. Enable JavaScript to search and browse every indexed mention.

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.