SaferCPlusPlus-AutoTranslation2
cppfront
SaferCPlusPlus-AutoTranslation2 | cppfront | |
---|---|---|
4 | 88 | |
8 | 5,132 | |
- | - | |
0.0 | 9.5 | |
about 2 years ago | 6 days ago | |
C++ | ||
Boost Software License 1.0 | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
SaferCPlusPlus-AutoTranslation2
-
United States White House Report on Memory Safe Programming [pdf]
Hi pizlonator, I'm working on a solution with similar goals (I think), but a bit of a different approach. It's a tool that auto-translates[1] (reasonable) C code to a memory-safe subset of C++. The goal is to get it reliable enough that it can be simply inserted as an (optional) build step, so that the source code can be maintained in its original form.
I'm under the impression that you're more of a low-level/compiler person, but I suggest that a higher level language like (a memory-safe subset of) C++ actually makes for a more desirable "intermediate representation" language, as it's amenable to maintaining information about the "intent" of the code, which can be helpful for optimization. It also allows programmers to provide manually optimized memory-safe implementations for performance-critical parts of the code.
The memory-safe subset of C++ is somewhat analogous to Rust's in terms of performance and in that it depends on a non-trivial static checker, but it imposes less onerous restrictions than Rust on single-threaded code.
The auto-translation tool already does the non-trivial (optimization) task of determining whether any (raw) pointer is being used as an array iterator or not. But further work to make the resulting code more performance optimal is needed. The task of optimizing a high-level "intermediate representation" language like (memory-safe) C++ is roughly analogous to optimizing lower-level IR languages, but the results should be more effective because you have more information about the original code, right?
I think this project could greatly benefit from the kind of effort you've displayed in yours.
[1]: https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...
-
Upcoming Changes to C++ : Bjarne Stroustrup, Gabriel Dos Reis.
Part of the reason the proposed static analyzer has to be so ambitious is because it's trying to validate (i.e. verify as safe) as much existing/legacy code as possible. An alternative approach is to autoconvert existing code to new code that is easier to verify as safe. One advantage of this approach is that in instances where you cannot (yet) statically verify safety, you can convert to (new) elements that may resort to run-time safety mechanism when necessary. With access to the full range of safety-performance tradeoffs, this approach can (fully) safen a much larger set of legacy code then any static analyzer alone could.
-
Some thoughts on safe C++
There's also some support for autoconverting legacy C code that is not performance critical to use the library and conform to a safe subset of C++.
cppfront
-
GCC 14.1 Release
CPP2/cppfront:
https://github.com/hsutter/cppfront
I hope we see this in C++26 as optional mode i.e. #safe and #unsafe and same for #impdef or so.
-
Compilation of gripping C++ conference talks from 2023
C++23 is done. But C++ is not! In this talk, the author shares his personal perspectives on an ongoing and very active evolution of C++, updates on his cppfront experimental compiler, and why compatibility is essential to the further success of the C++ development.
- Show HN: a Rust Based CLI tool 'imgcatr' for displaying images
- Cpp2 and cppfront – An experimental 'C++ syntax 2' and its first compiler
-
C++ Safety, in Context
https://github.com/hsutter/cppfront
But his side project at Microsoft didn't gain traction with gcc, clang, etc and everybody else in the industry. So at this point, the C++ committee will be perceived as "so far behind" ... because there's nothing for them to vote on.
- Cppfront: Experimental C++ Syntax 2 –> Syntax 1 compiler
- Odin Programming Language
- Cppfront
-
C++ Should Be C++
C++ has major flaws that cannot be rectified without serious breaking changes. With that said, Herb has been experimenting with a new cpp frontend with sane defaults [1].
In my opinion, the world is on standby until Anders Hejlsberg feels like tackling a modern, next generation systems language.
[1] https://github.com/hsutter/cppfront
- Why is the committee so reluctant to add new features to the language itself instead of stuffing them into the STL?
What are some alternatives?
carbon-lang - Carbon Language's main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)
jakt - The Jakt Programming Language
serenity - The Serenity Operating System 🐞
zig - General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
exotracker-cpp
LoopModels - "Full speed or nothing." - James Hetfield
modern-cpp-features - A cheatsheet of modern C++ language and library features.
CppCoreGuidelines - The C++ Core Guidelines are a set of tried-and-true guidelines, rules, and best practices about coding in C++
gx - A Go->C++transpiler meant for data-oriented gameplay and application programming especially for WebAssembly. Using this mostly in the context of specific personal projects and heavily focusing the feature set on those. Used in my Raylib gamejam project: https://github.com/nikki93/raylib-5k -- also being used to develop a private longer term game project and a note-taking app.
Robyn - Robyn is a Super Fast Async Python Web Framework with a Rust runtime.
unsafe-python - A library to assist writing memory-unsafe code in "pure" python, without any imports (i.e. no ctypes etc.)
dmd - dmd D Programming Language compiler