GSL
CppCoreGuidelines
GSL | CppCoreGuidelines | |
---|---|---|
23 | 318 | |
6,294 | 43,220 | |
0.6% | 0.4% | |
7.5 | 7.0 | |
about 1 month ago | 22 days ago | |
C++ | CSS | |
GNU General Public License v3.0 or later | 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.
GSL
-
21st Century C++
I haven't read much from Bjarne but this is refreshingly self-aware and paints a hopeful path to standardize around "the good parts" of C++.
As a C++ newbie I just don't understand the recommended path I'm supposed to follow, though. It seems to be a mix of "a book of guidelines" and "a package that shows you how you should be using those guidelines via implementation of their principles".
After some digging it looks like the guidebook is the "C++ Core Guidelines":
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
And that I should read it and then:
> use parts of the standard library and add a tiny library to make use of the guidelines convenient and efficient (the Guidelines Support Library, GSL).
Which seems to be this (at least Microsoft's implementation):
https://github.com/microsoft/GSL
And I'm left wondering, is this just how C++ is? Can't the language provide tooling for me to better adhere to its guidelines, bake in "blessed" features and deprecate what Bjarne calls, "the use of low-level, inefficient, and error-prone features"?
-
60 terrible tips for a C++ developer
Already showed you how to use ranges and such above, gsl::final_action is here
-
Backward compatible implementations of newer standards constructs?
For span I would recommend the guideline support library - gsl::span
-
Hey Rustaceans! Got a question? Ask here (20/2023)!
Not sure how things are at this point so you might want to look up with those keywords, but a few years back clang-tidy was one of the suggested tools, or enabling the core guidelines checker in visual studio if you're using that. Maybe using GSL or something similar as well.
-
Hardening C++ with Bjarne Stroustrup
When I want safety guarantees, I use the original and run-time checked gsl::span, rather than std::span. https://github.com/microsoft/GSL .
-
I love building a startup in Rust. I wouldn't pick it again.
Another solution: use std::span (or some alternative implementations if the codebase doesn't use C++20).
-
C++23 “Pandemic Edition” is complete
If you ask me, the GSL [1] alone is a fairly radical departure from C++ that delivers a lot of safety. I don't know if it's gotten much popularity, though. Probably because it introduces a similar disruption like you might find from a brand new programming language.
[1] https://github.com/microsoft/GSL
-
Using Rust at a startup: A cautionary tale
> With Rust, though, one needs to learn entirely new ideas — things like lifetimes, ownership, and the borrow checker. These are not familiar concepts to most people working in other common languages ... Some of those “new” ideas are, of course, present in other languages — especially functional ones.
With C++, lifetime and ownership are just about as important but unfortunately no one's got your back. You can ignore lifetimes and ownership but you do so at your own peril. And the compiler won't tell you you're doing it wrong because the language wasn't designed for it to do so.
If you want a taste of rust's "mindset" (with respect to limitations imposed by some types) without jumping ship to a new language, try C++'s Guidelines Support Library [1]. It introduces some of the same benefits/friction as switching to rust but without a new language. Opting-in to some of these guidelines might be a gentler way to get some of the benefits of Rust. But it comes with a similarly higher bar.
[1] https://github.com/microsoft/GSL
- Passing a std:: array as a function parameter
-
I created a memory leak using smart pointers
It's also far more verbose than T* or T& (probably intentionally). If you really want a non-nullable pointer, gsl::not_null from the GSL is a good option. Writing your own version is also trivial, if you don't want to add a dependency.
CppCoreGuidelines
-
21st Century C++
I haven't read much from Bjarne but this is refreshingly self-aware and paints a hopeful path to standardize around "the good parts" of C++.
As a C++ newbie I just don't understand the recommended path I'm supposed to follow, though. It seems to be a mix of "a book of guidelines" and "a package that shows you how you should be using those guidelines via implementation of their principles".
After some digging it looks like the guidebook is the "C++ Core Guidelines":
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
And that I should read it and then:
> use parts of the standard library and add a tiny library to make use of the guidelines convenient and efficient (the Guidelines Support Library, GSL).
Which seems to be this (at least Microsoft's implementation):
https://github.com/microsoft/GSL
And I'm left wondering, is this just how C++ is? Can't the language provide tooling for me to better adhere to its guidelines, bake in "blessed" features and deprecate what Bjarne calls, "the use of low-level, inefficient, and error-prone features"?
-
Ray Tracing in One Weekend
See this: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...
Technically, headers are just copy-paste, obviously. However, there's value to keeping them as standalone as possible.
- Rust in QEMU Roadmap
-
Don't defer Close() on writable files
> close a file (which ironically is the poster child for RAII)
Yes, I call this "RAII is a lie" (T-shirt pending).
Closing file descriptors is univerally used to showcase RAII, but it should never be used for that.
C++ has the same problem:
https://github.com/isocpp/CppCoreGuidelines/issues/2203
In there, it is acknowledged that a manual Close() should always be provided, and used if you want guarantees.
> is a bad pattern
Good that Rust at least figured it out early that it's a bad pattern!
Never use RAII in situations where the cleanup can fail!
- CppCoreGuidelines: Essential Rules and Best Practices for C++ Developers
-
What to do if you don't want a default constructor?
The standard library types are guaranteed to be in a useful state after being moved from (the term "valid state" is used for this). Of course, that doesn't mean that your own types have to, but the C++ Core Guidelines suggest doing so [1].
1: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...
-
I Have No Constructor, and I Must Initialize
It’s in the cpp core guidelines: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...
std::reference_wrapper still can’t save you from yourself, but its slightly better.
-
Fixing a memory leak of xmlEntityPtr in librsvg
Slightly tongue in cheek answer: it is easy to write this kind of code in C++ without having C involved, hence style guides will usually have a prominent guideline specifically against this type of code[1].
In Rust, I think you only really run into this issue when interacting with C (or otherwise engaging in unsafe code), so for normal Rust coding it doesn't need to be spelled out as a guideline. And the Rustonomicon[2], the go-to resource for unsafe Rust, isn't really written as a set of guidelines. At least from a brief search, I found it harder to find a Rust page that specifically says "don't do this".
1: E.g. https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines..., the first guideline in the "resource management" section.
2: https://doc.rust-lang.org/nomicon/intro.html
- Zig vs. Rust at work: the choice we made
- C++ Core Guidelines
What are some alternatives?
cppinsights - C++ Insights - See your source code with the eyes of a compiler
Crafting Interpreters - Repository for the book "Crafting Interpreters"
span-lite - span lite - A C++20-like span for C++98, C++11 and later in a single-file header-only library
git-internals-pdf - PDF on Git Internals
boost - My personal boost mirror to be submoduled by my projects
github-cheat-sheet - A list of cool features of Git and GitHub.
sentry-native - Sentry SDK for C, C++ and native applications.
Power-Fx - Power Fx low-code programming language
C-Golang-like-Defer - Cursed defer() method in C++ achieves similar results as Go's defer keyword.
learnxinyminutes-docs - Code documentation written as code! How novel and totally my idea!
cpp-core-guidelines-cheatsheet - Cheatsheet for the C++ core guidelines, including a set of tried-and-true guidelines, rules, and best practices about coding in C++.
too-many-lists - Learn Rust by writing Entirely Too Many linked lists