Mon 23 December 2024

1️⃣ Year of Sane C++

SC

Time flies, it's been already one year since the first public release of Sane C++ Libraries!

Sane C++ Libraries is a set of C++ platform abstraction libraries for macOS, Windows and Linux based on the following Principles:

✅ Fast compile times
✅ Bloat free
✅ Simple and readable code
✅ Easy to integrate
⛔️ No C++ Standard Library / Exceptions / RTTI
⛔️ No third party build dependencies (prefer OS API)

Sane C++ Libraries can be used without the C++ Standard Library but it's NOT a STL replacement, and it doesn't try to be that.

Each library is color-coded to signal its status:

🟥 Draft (incomplete, WIP, works on basic case)
🟨 MVP (minimum set of features have been implemented)
🟩 Usable (a reasonable set of useful features has been implemented)
🟦 Complete (all planned features have been implemented)

New 2024 additions

Supported platforms and architectures

🟩 Usable Libraries

Promoted from 🟨 MVP to 🟩 Usable state

🟩 SC::Process
🟩 SC::FileSystem
🟩 SC::FileSystemIterator
🟩 SC::FileSystemWatcher

🟨 MVP Libraries

Promoted from 🟥 Draft to 🟨 MVP state

🟨 SC::Build
🟨 SC::Plugin
🟨 SC::File

🛜 SC::Async

🟨 Async I/O library (files, sockets, timers, processes, fs events, wake-up)

See SC::Async

This is the most advanced library of the project, designed to do exactly 0 dynamic allocations and it got stability and quality of life improvements.

Think of a simplified libuv / Boost.ASIO that covers most of their features in a very compact codebase written according to the Sane C++ Principles!

🟢 No allocations!
🟢 Socket operations (send/receive/connect/accept)
🟢 File operations (read/write/close)
🟢 Child process watcher
🟢 Folder watcher
🟢 Background Threaded Work

Backends:

🟢 epoll
🟢 io_uring
🟢 kqueue
🟢 IOCP

Notes:

📝 SCExample

WIP example browser showcase for the library

See SC::Example

🟢 Based on Dear ImGui and sokol libraries ❤️
🟢 Power Efficient: redraws on SC::Async IO or input events
🟢 Hot-reloaded on the fly through SC::Plugin
🟢 Integrates SC::Async with native event Loop
🟢 Supports macOS, iOS, Linux and Windows

Running on macOS:


Running on iOS:

🛠️ SC::Tools

Single C++ "scripts" compiled on the fly for immediate execution

SC::Tools replace all shell automation scripts in the project with real C++ programs dog-fooding Sane C++ Libraries themselves.

🟢 SC::Build

🟢 SC::Package

🟢 SC::Format

🔨 SC::Build

🟨 Minimal self-hosted build system where builds are described in C++

See SC::Build

🟢 Support generating multiple projects from a single definition
🟢 Support generating Makefile for Linux and macOS
🟢 Support generating macOS and iOS bundles with icons for XCode
🟢 Support building specific configuration and architecture
🟢 Support paths with spaces 😎
🟢 Simplify build definition
🟢 Support generating projects for Windows subsystem
🟢 Add new actions:

⚖️ SC::Process

🟩 Create Child processes, chain them, read outputs.

See SC::Process

🟢 Improve API ease of use
🟢 Improve stability and reliability on Posix
🟢 Support custom working directory
🟢 Support custom environment variables
🟢 Support ignoring child process stdout/stderr

🔌 SC::Plugin

🟨 Minimal dependency based plugin system with hot-reload

See SC::Plugin

🟢 Allow overriding sysroot path
🟢 Capture compiler and linker output
🟢 Intercept and use environment CFLAGS / LDFLAGS
🟢 QueryInterface-like mechanism
🟢 Multiple include paths
🟢 Track number of reloads and load time for plugins
🟢 Detect Visual Studio Path dynamically

👀 SC::FileSystemWatcher

🟩 Notifications {add, remove, rename, modified} for files and directories

See SC::FileSystemWatcher

🟢 Improve reliability
🟢 Support iOS using the (private) FSEvents framework
🟢 Can monitor files in a background thread or using SC::Async

🗃️ SC::FileSystem

🟩 File System operations { exists, copy, delete } for { files and directories }

See SC::FileSystem

🟢 Improve reliability
🟢 Symlinks creation

#️⃣ SC::Hashing

🟩 Compute MD5, SHA1 or SHA256 hashes for a stream of bytes

See SC::Hashing

🟢 C Bindings

🕸️ SC::Http

🟥 HTTP parser, client and server

See SC::Http

🟢 Improved to the level of self-hosting this website (non-production)

🚰 SC::AsyncStreams

🟥 Read / transform / write data concurrently from async sources to destinations.

See SC::AsyncStreams

🟢 Inspired from node.js streams
🟢 Back-pressure handling
🟢 Readable Streams (Sources)
🟢 Writable Streams (Sinks / Destinations)
🟢 Transform Streams
🟢 Pipelines (Source -> Transforms -> Multiple Sinks)

API is still very WIP

🤖 Continuous Integration

🟢 Runs using GitHub runners
🟢 Tests run on Windows Server 2019 / 2022, Linux and macOS
🟢 No shell scripting (uses SC::Tools)
🟢 No external dependencies other than doxygen for docs and clang
🟢 Verifies code to be formatted properly on all Pull Requests
🟢 Builds and publishes documentation at every commit
🟢 Computes and publishes code coverage at every commit

🤳 YouTube

🟢 32 YouTube videos produced

I've always liked the idea of producing some videos to shed some light on the development process and get better at explaining myself. This has been taking a little bit of time away from actual coding, but I enjoyed doing them!

Take a look at my YouTube Channel if you're interested!

📒 Blog

🟢 10 Blog Posts written

Writing update blog post has also been consuming some time but it was worth it.
I think it's a nice way to keep up to date with latest additions of the projects spending a very minimal amount of readers time.

What's next

It's important not to lose focus and continuing to improve existing libraries.

It feels like the most advanced functionality is already in the Async I/O capability of the libraries, but there is still so much to do.

It would be great improving SC::Async to make it competitive with more famous libraries like Boost.Asio and libuv. Ideally SC::Async should cover 80% of common use cases but with a much smaller and faster to compile code base. The C-API for SC::Async should try to be close to libuv. Can we make it so that unmodified libuv programs can be compiled against such C-API?

SC::AsyncStreams should be improved to bring higher level functionality that exists in successful server runtimes like node.js.

SC::Http should grow to support enough HTTP 1.1 to become useful at least to create a quick webserver when it's needed. WebSocket should be implemented on top of it. It would be great to implement HTTPS support without needing to include and link an external library like OpenSSL. Exploring the proper Windows and macOS API to do proper handshake and cryptography will be very useful.

How much of these objectives will be achievable highly depends on if the solo development experience will continue to be the norm.

See you soon!!🎊👋🏼