Where do we even start?#
So...where do I even start?
This is probably just an articulation of my multi-decade old opinion on
How should C++ be written™ that nobody has ever asked for 🤭.
Modern C++ and Standard C++ Library
I find Modern C++ style problematic 😩, causing large increases in compile time and binary size, frequent confusion caused to code completion engines, and micro-heap-allocations habits engraved in a mountain of hard-to-understand code.Many of these (and other) problems are not easily avoidable when using the Standard C++ Library, making it too easy descending into an endless hole of growing complexity.
Handmade C
On the other side of the spectrum I observe so many proudly handmade developers sticking to C or coming up with new languages sharing similar minimalistic spirit.I'm definitively more spiritually affine to readable and well written C 🧘🏻♂️, rather than Modern C++.
I often feel however that such libraries are rare (
sqlite, sokol,
stb, raylib etc.) and it takes a lot of discipline and experience to stick
successfully to such clean and coherent style.Other languages and libraries#
Many programming languages come with a standard library designed to solve common user needs.
That's not the case for C++ though, where any non trivial project will have to integrate
third party libraries to do anything significant.
Integrating such libraries morphs C++ projects into a patchwork of incoherent programming styles,
as direct derivation of the subset of language features chosen by the authors.
Sometimes these incoherences become actual bad practices producing hard to read and maintain code, bugs,
instabilities, inefficiencies and security issues.
The holy hidden subset of C++#
This project is a journey of defining and discovering a C++ subset that makes writing code with it enjoyable
😌.
Libraries should be working harmonically with each other while still making it possible to use them in
isolation or with minimum inter-dependencies.
This holy hidden C++ subset should encourage writing readable programs that are efficient and fast to
compile while still being easy to develop / debug / deploy and reasonably safe on multiple platforms.
The edit / recompile cycle should ideally be closer to the ones of highly productive languages
like Python and Javascript than the average C++ project / library.
Defining the scope#
So what is the initial scope of the library?
Basic building blocks
The very first basic building blocks are a good API for: async IO / networking, file system and process handling, serialization, text (with utf support), json and http.Data structures and algorithms
Data structures and algorithms are for now secondary, but the library comes with a solidVector T implementation with support for custom inline storage
SmallVector T, N.
Proper arena allocation / release strategies will be explored too.
User Interfaces
User interfaces abstraction are excluded (for now).Once most of the libraries will be in MVP or Stable the topic will be revisited.
Integrations
It's very important showing how to integrate libraries inside such system specific GUI libraries / toolkits.For example it could be not obvious how to properly integrate the Async IO event loop inside a GUI event loop. Providing ready-made examples for such setups is going to be very useful to many users of the libraries.
Self-hosted build system
An optional to use build system, where build files are written in imperative C++ code (compiled on the fly) is being worked on. The build system links the rest of library compiled as a single unity build.Some rules#
Some rules used in the project:
- Libraries will not use C++ standard library at all.
- Libraries will not need a build system to be integrated in existing projects.
- Libraries will not increase build time when integrated into existing projects.
- Libraries will compile free of warnings on all major C++ compilers (Clang, GCC, MSVC).
- Libraries will try to avoid heap allocation and make efforts to let caller handle such memory.
- Libraries will have proper tests and documentation.
- Libraries will focus on common use cases rather than trying to cover every possible use case.
Dependencies#
General advice is to avoid using 3rd party libraries as much as possible.
There are some cases where it's simply unreasonable not using any third party library.
Windows and macOS native APIs are being leveraged to avoid needing libraries (a good example is the
Hashing library).
On Linux however some of these API are not part of the kernel, are typically part of user-space
libraries. Such libraries will need to be installed with apt-get or delivered by wrapping some
3rd party dependency.
In any case if 3rd party libraries will be used, they will be made optional and properly wrapped in
a way that they will be an hidden implementation detail.
Building the library will still not require a build system and it will still be fast to compile.
No derogation will be made to these principles.
Maturity#
The project is being open-sourced in its very early stages.
Libraries have different level of maturity, stated in the documentations with a brief roadmap.
As of today, when this post is written, they're mostly in Draft or MVP state.
No guarantee is being done for API stability too for now.
Platforms#
Initially, the only supported platforms are macOS and Windows.
A partial port to Emscripten / WebAssembly is also being worked on.
Linux support is one explicit bullet point in the roadmap of all libraries that use OS specific API.
Compatibility on iOS will be explored too.
Licensing#
The project is MIT licensed, so it should make things easy for any potential adopter.
Conclusions#
It'll be fun! 😎