Hi everyone,
With the recent ISO committee and compiler-level debates surrounding memory safety in C++, I have been researching some alternative, library-based ways to enforce deterministic heap-bound protection without having to modify the compiler frontend or language specification itself.
I’ve been working on a runtime library called Safe--Cpp, which specifically focuses on ensuring that heap allocations achieve the same level of compile-time safety as Rust, but managed purely through language runtime mechanics rather than compile-time static borrow checking or ownership checking. I want to emphasize that this research strictly focuses on a custom safe context to prevent 4 types of memory errors: Double Deletion, Access Violation, Buffer Overflow and Memory Leaks.
# Core Architectural Concepts Under Investigation:
1. Strict Heap Boundary Enforcement: Tracking the initialization and destruction boundaries of objects explicitly allocated on the heap, ensuring references cannot outlive their allocation scope.
2. Explicit Lifetime Invalidation: The runtime library tracks every heap-allocated instance of types that inherit from
Safe::SafeContextBase and offers recycling/repurpose mechanisms to gain performance instead of relying on deallocations which require accessing the operating system kernels to perform system calls, invalidates the need of reference counting like in `std::shared_ptr`.3. No External Tooling Dependencies: The runtime mechanics are implemented strictly using platform capabilities and the standard C++ language.
# Seeking Feedback on the Implementation
I have opened up the complete source and headers of this implementation under a Source-Available model (PolyForm Noncommercial License) so that other system engineers and language researchers can audit the exact low-level mechanics.
👉 GitHub Repository: https://www.github.com/ducna-vbee/Safe--Cpp
Rather than discussing the philosophical pros and cons of memory models, I am looking for concrete technical review, potential bug identification, and feature suggestions to help push the boundaries of what standard C++ can do here.
Specifically, I would love your insights on:
1. Bugs & Safety Violations: Are there subtle ways to bypass the context boundaries or trick the `SafeContextBase` lifecycle tracking using advanced modern C++ features (e.g., specific combinations of move semantics, perfect forwarding, or custom allocators) that could still lead to a leak or access violation?
2. Performance Improvements & Language Limits: The engine bypasses OS kernel allocations by providing instance recycling and repurposing mechanics. How can this layout be optimized further to reduce CPU cache misses or minimize the tracking metadata overhead? Which aspects of memory allocation can be made safe under the safe context? Can the memory stack also be as safe as the memory heap, like in Rust, without the borrow checker?
3. API & New Feature Suggestions: What missing features or API improvements would make this runtime context significantly easier to integrate into existing real-world standard C++ codebases without degrading performance?
Please feel free to check out the source, run your own benchmarks, and leave your feedback or file an issue directly on the repository!
https://redd.it/1upj6at
@r_cpp
