cxxopts is a lightweight, header-only C++ library for parsing command-line options following GNU-style syntax. It supports short (-a), long (--option), combined short options (-abc), value attachment via space or equals sign, positional arguments, implicit and default values, boolean flags, vector options with configurable delimiters, and multiple long aliases per option. The library is implemented entirely in a single header file (include/cxxopts.hpp) and requires a C++11 compiler. It provides a clean API: create a cxxopts::Options object, define options via add_options(), parse argc/argv with parse(), and retrieve values from the returned ParseResult. Exceptions are used for error handling but can be disabled via CXXOPTS_NO_EXCEPTIONS. The library has comprehensive test coverage using Catch, continuous integration with CMake, Meson, and Bazel build systems, and includes fuzz testing via OSS-Fuzz. It is mature, well-maintained, and widely adopted (over 4800 GitHub stars). The architecture is monolithic but well-organized, with clear separation of concerns between option definition, value storage, parsing logic, and help text generation. External dependencies are optional: ICU for Unicode help output and std::optional/std::filesystem when available. There are no isolated subcomponents that can be extracted without modification, as the entire library is designed as a cohesive single-file unit.
Fruit is a C++ dependency injection framework that enforces binding correctness at compile time through heavy template metaprogramming, loosely inspired by Google Guice for Java. The core architecture consists of a public fluent API (Component, Injector, Provider, NormalizedComponent) backed by an internal metaprogramming library for compile-time validation and runtime graph traversal using custom high-performance data structures (SemistaticGraph, SemistaticMap, FixedSizeAllocator). Users declare components via createComponent() chaining, which produces type-safe binding graphs; the framework then generates efficient object construction code with lazy/eager injection, multibindings, and component replacement for testing. The repository also includes a comprehensive benchmark suite that compares Fruit against Boost.DI and hand-written injection, along with parallel build system support (CMake, Bazel, Conan) and cross-platform CI covering GCC, Clang, MSVC across Linux, macOS, and Windows.
SRS (Simple Realtime Server) is a high-performance, multi-protocol media streaming server primarily written in C++ with a newer Go-based proxy component (SRSX). It ingests, processes, and delivers live audio/video streams via RTMP, WebRTC (WHIP/WHEP), HLS, HTTP-FLV, SRT, and GB28181. The core C++ engine uses a coroutine model built on state-threads, implements stream forwarding, transcoding via FFmpeg, and provides a full HTTP API for management. The Go proxy component (cmd/proxy, internal/) adds load balancing, Redis integration, and protocol proxying for RTMP/HTTP/WebRTC, designed to scale origin/edge deployments. The repository also includes extensive research code, blackbox integration tests, and vendored third-party libraries (FFmpeg 4, OpenSSL 1.1, gperftools, SRT, libsrtp) that have been customized with a '-fit' suffix. This hybrid architecture is actively developed with multiple CI workflows and a large test suite, though some vendored dependencies are older and may require security updates.
OpenSCAD is a mature, script-based 3D CAD modeler. It provides a declarative language for defining solid geometry through Constructive Solid Geometry (CSG) operations, extrusions, and transformations. The application consists of a C++ core that parses the custom scripting language, builds an AST, and evaluates geometry using either the CGAL or Manifold library for boolean operations. Rendering is handled via OpenGL with both preview (OpenCSG) and final render modes. The GUI, built on Qt, includes a code editor with syntax highlighting, a 3D viewport, parameter customizer, and an integrated AI assistant for code generation. Exports to STL, OBJ, SVG, 3MF, PDF, and other formats. The codebase demonstrates strong engineering with clear module separation (core, geometry, glview, gui, io, utils), extensive regression tests, and reusable patterns such as visitors, builders, and self-contained geometry utilities.
This is the Intel RealSense SDK 2.0 (librealsense), a cross-platform C++ library for controlling and streaming data from Intel RealSense depth cameras (D400, D500 series). It provides a unified API for depth, color, infrared, and IMU streams, with hardware abstraction layers for USB (libusb, WinUSB, USBHost), UVC, HID, MIPI, and DDS (Data Distribution Service) network transport. The SDK includes a rich processing pipeline with composable filters (alignment, point cloud generation, decimation, temporal/spatial filtering, HDR merge, colorization) and supports GPU acceleration via CUDA, HIP, OpenGL, and NEON SIMD. It is not a single application but a library with multiple end-user tools (RealSense Viewer, firmware updater, ROS bag converter, DDS adapter, REST API server) and extensive language wrappers for Python, C#, Java/Android, Unity, Unreal Engine, MATLAB, OpenCV, and OpenNI2. The codebase is well-engineered with a modular architecture, extensive unit/integration tests (including live hardware tests), and a comprehensive build system (CMake with vendored third-party dependencies). While the core is actively maintained and demonstrates strong craftsmanship, the large surface area of wrappers and vendored dependencies introduces some technical drift (e.g., outdated ROS Kinetic generated headers, old Unity project version).
FLIP Fluids is a production-grade Blender addon for liquid simulation, integrating a custom C++ FLIP (Fluid Implicit Particle) engine with a comprehensive Python UI. The engine implements advanced numerical methods including level sets, variational pressure solvers, PCG with MIC(0) preconditioning, force fields, whitewater particles, and viscosity solvers, all backed by a vendored Eigen linear algebra library. The Blender addon provides property groups, UI panels, preset management, material libraries, and command-line scripts for baking, rendering, and Alembic/USD export. The architecture is a hybrid: the C++ engine is compiled as a shared library and accessed via C bindings and Python ctypes wrappers, while the addon code follows standard Blender patterns (operators, panels, property groups). Key entry points include the baking operators, simulation domain properties, and the engine's Python bindings in `ffengine/`. External dependencies include Blender (4.5+), Eigen, and optionally Mixbox for color blending. The codebase is well-structured with extensive version compatibility layers, but the vendored Eigen and reliance on Blender's evolving API introduce moderate technical drift.
evmone is a high-performance Ethereum Virtual Machine (EVM) implementation written in C++20, designed as a plugin for Ethereum clients via the EVMC interface. It provides two execution engines: a baseline interpreter using computed goto dispatch for simplicity and speed, and an advanced interpreter using indirect call threading with precomputed basic block analysis for further optimization. The implementation supports all EVM revisions from Frontier through the upcoming Amsterdam, including precompiled contracts for cryptographic operations such as SHA-256, RIPEMD-160, BLAKE2b, BN254 pairings, BLS12-381, KZG point evaluation, and secp256r1 verification. The codebase is structured as a shared library (libevmone) with a CLI tool (evmone) for running bytecode and executing state transitions (t8n), along with extensive benchmarking and testing infrastructure. The architecture is modular: core EVM logic resides in lib/evmone/, precompiled contracts in lib/evmone_precompiles/, and test utilities in test/. The project uses CMake with Hunter for dependency management and includes a self-contained CMake bootstrap library (Cable) for build configuration. It features a comprehensive test suite including unit tests (Google Test), state transition tests, blockchain tests, fuzzing, and integration tests against Ethereum execution-spec-tests. The code demonstrates strong engineering practices with heavy use of templates, constexpr, and platform-specific optimizations (e.g., SHA-NI, BMI) while maintaining portability across x86, ARM, and RISC-V. Notable reusable components include a generic LRU cache, Montgomery modular arithmetic for arbitrary precision, a bytecode construction DSL for testing, a generic elliptic curve library, and a modular exponentiation implementation with CIOS multiplication. The project is actively maintained with frequent releases tracking Ethereum protocol upgrades, and its design emphasizes performance without sacrificing correctness, as evidenced by rigorous testing and fuzzing.
Uno is a modular C++ solver for nonlinearly constrained optimization (NLP, QP, LP). It implements a unification framework that combines interchangeable algorithmic ingredients—constraint relaxation strategies, inequality handling methods, Hessian models (exact, quasi-Newton, identity, zero), inertia correction, subproblem solvers (QP/LP), and globalization mechanisms (line search, trust region, filter, funnel). The solver supports both sequential quadratic programming (SQP) and interior-point methods, and can be configured via presets that mimic established solvers like filterSQP and IPOPT. The architecture is a library with a main orchestration loop in `Uno.cpp`. The user defines the optimization problem through callback functions (objective, gradient, Jacobian, Hessian) via a C API, which is then wrapped by interfaces for AMPL, Fortran, Julia, and Python. Internally, the solver builds a regularized KKT system, delegates subproblem solves to external libraries (HiGHS, BQPD, HSL MA27/57/86, MUMPS, SPRAL), and applies globalization to ensure convergence. The codebase is heavily templated and uses expression templates for linear algebra, factory patterns for component selection, and runtime dynamic loading for optional dependencies. Key entry points include `uno_optimize()` (C API), `UnoSolverWrapper::optimize()` (Python), and the AMPL executable `uno_ampl`. The solver is used in research and production environments via JuMP.jl, CasADi, pyOptSparse, and OpenMDAO. External dependencies include BLAS/LAPACK, HSL (proprietary), MUMPS, SPRAL, HiGHS, BQPD, and AMPL ASL. The project is actively maintained with extensive CI, cross-platform builds, and a growing ecosystem of language bindings.
ImHex is a cross-platform hex editor and binary analysis tool designed for reverse engineers, programmers, and digital forensics. It provides a rich GUI built on Dear ImGui and GLFW, with a modular plugin architecture that allows extending functionality through dynamically loaded plugins. The core library (libimhex) implements a provider abstraction for various data sources (files, disks, process memory, GDB, SSH, UDP, etc.), an event-driven communication system, a content registry for registering views, tools, settings, and data inspectors, and a pattern language engine for declarative binary parsing. The application includes built-in plugins for hex editing, data inspection, disassembly (Capstone), diffing, YARA rule matching, hashing, decompression, visualizations (3D, plots, images), scripting (C and .NET), and a Model Context Protocol (MCP) server for AI-assisted analysis. It supports undo/redo, bookmarks, patches, projects, themes, layouts, achievements, tutorials, and a command palette. The codebase is well-structured with clear separation between core library, plugins, and platform-specific code, though some components are tightly coupled to ImGui internals and the custom pattern language.
ArrayFire is a mature, production-grade tensor and array computing library implemented in C++, exposing both a C API (af_* functions) and a C++ API (af::array). It provides hundreds of accelerated numerical operations — dense and sparse linear algebra (LU, QR, SVD, Cholesky, solve), FFT and signal processing, image transforms and filtering, computer vision feature detection (FAST, SIFT, ORB, SUSAN, homography), statistics, and random number generation — across four hardware backends: CPU, CUDA, OpenCL, and oneAPI/SYCL. The architecture is layered: thin C API wrappers and C++ classes in src/api/c and src/api/cpp dispatch through a unified runtime layer (src/api/unified) that lazily loads backend shared libraries via a symbol manager; each backend implements the same templated operation set over device-resident arrays with backend-specific kernels under src/backend/*/kernel. The genuinely interesting engineering lives in src/backend/common: a JIT expression-tree system that fuses array operations into compiled kernels, deterministic hash-based kernel caching, a memory manager with JIT-pressure eviction heuristics, FFT plan caching, and cross-platform dynamic library loading. The test suite is unusually rigorous for a numerical library — well over 100 gtest programs covering correctness across all dtypes, large dimensions, random-number quality via PractRand, and death tests — while examples span image processing, machine learning, financial Monte Carlo, and PDE simulation. Maintenance is active (commits through 2026, CI workflows, source releases), but technical drift is medium: the oneAPI backend is explicitly incomplete with many operations stubbed as ONEAPI_NOT_SUPPORTED, deprecated compatibility APIs remain (include/af/compatible.h), the four backends duplicate a large amount of near-identical code, and some packaging artifacts (Tegra toolchain pinned to gcc-5, vendored vcpkg LAPACK patches, Debian postinst hardcoding MKL/CUDA paths) are stale. This is a software library rather than a data pipeline — there are no notebooks, datasets, or analytical artifacts — though its algorithms are directly applicable to computer vision and scientific computing workloads.
B3DFramework (namespace `b3d`, legacy `bsf` path prefixes) is a cross-platform C++17 game/application engine framework. Production code reveals a complete runtime: a scene/component model with ECS fragments, dirty-flag transform hierarchy propagation, prefab/scene serialization, async resource handles, and a plugin architecture with GPU backends (Vulkan, D3D12, Metal, Null), physics (PhysX), audio (FMOD, OpenAL), and a default renderer (RenderBeast). The engine implements its own shader language (BSL) with a compiling pipeline, a custom RTTI/reflection system with versioned binary serialization and delta compression, and a Mono-based C# scripting layer generated from C++ types via a codegen toolchain.
This is a software library for parsing and processing IFC (Industry Foundation Classes) BIM files, primarily designed for web environments. It consists of a C++ core that reads IFC STEP files, resolves geometry (including extrusions, sweeps, Boolean CSG operations, and advanced curves like B-splines and clothoids), and generates triangulated meshes. The C++ code is compiled to WebAssembly via Emscripten, and a TypeScript API (IfcAPI) exposes all functionality to JavaScript applications in both browser and Node.js. The library supports multiple IFC schema versions (IFC2X3, IFC4, IFC4X3) and includes a schema generator that produces C++ and TypeScript type definitions from EXPRESS schema files. The architecture is a classic native-to-web bridge: the C++ library handles all heavy geometry and parsing, while the TypeScript layer provides a clean interface for loading models, streaming meshes, reading/writing properties, and creating new geometry. Key entry points include the IfcAPI class (open/close models, load geometry, save models), the C++ IfcGeometryProcessor and IfcGeometryLoader for mesh generation, and the IfcLoader for token-based IFC parsing. External dependencies include GLM (math), spdlog (logging), mapbox/earcut (triangulation), and CDT (constrained Delaunay triangulation). A comprehensive test suite using real IFC files and regression hash checks ensures geometry stability across versions. The library is production-ready but shows some technical drift: pinned dependency commits, large monolithic source files, and generated schema headers that must be manually regenerated. It remains actively maintained with CI/CD pipelines, issue triage, and regular releases (v0.0.78).
Boost.GIL (Generic Image Library) is a mature, header-only C++14 library for generic image processing, part of the Boost collection. It abstracts image representations from algorithms using template metaprogramming, enabling compile-time polymorphism and performance comparable to hand-written code for specific image types. The library provides core abstractions for pixels, channels, color spaces, image views, locators, and iterators, alongside a comprehensive I/O extension supporting JPEG, PNG, TIFF, BMP, PNM, Targa, and RAW formats. Image processing capabilities include convolution, thresholding (binary, adaptive, Otsu), histogram equalization/matching, morphological operations, edge detection (Sobel, Scharr, Harris, Hessian), Hough transforms (lines, circles), anisotropic diffusion, Lanczos resampling, and rasterization of geometric primitives. The library is designed for both application development and research, with a strong emphasis on extensibility, performance, and portability across compilers. While primarily a production-quality library, its extensive use of concepts and metafunctions also makes it a valuable resource for studying generic programming patterns in C++.
DB Browser for SQLite is a desktop GUI application written in C++/Qt for creating, browsing, editing, and querying SQLite databases. The core is a QMainWindow (src/MainWindow.cpp) with dockable table browsing, a schema tree, an SQL editor, plot dock, and many modal dialogs for table/index design, CSV/SQL/JSON import/export, encryption, preferences, and conditional formatting. SQLite is accessed through a custom DBBrowserDB wrapper (src/sqlitedb.cpp), with threaded execution via RunSql and RowLoader, and a custom flex/bison SQL parser feeds the sqlb object model (src/sql/sqlitetypes.cpp) for schema introspection and SQL generation. Data flows center on files: a user opens an SQLite database or project, schema is introspected into sqlb::Table/View/Index objects, rows are fetched asynchronously into a SqliteTableModel backed by RowCache, edits are applied with SQL savepoints, and exports stream via the SQLite C API to CSV/JSON/SQL. The SQL editor is QScintilla with a project-specific SqlUiLexer for SQLite keyword completion. The repository vendors large third-party libraries (QScintilla/Scintilla 2.14.1, QCustomPlot, QHexEdit, nlohmann/json), bundled for portability but adding maintenance overhead. Engineering quality is solid: a modular CMake build, unit tests under src/tests, GitHub Actions CI for Windows/macOS/Linux, and a clean separation between the database layer, SQL object model, Qt models, and dialogs. Several components are self-contained enough for reuse, including ObjectIdentifier, RowCache, CSVParser, and the Data helper utilities. Technical drift is medium: the bundled QScintilla is old, some Qt5-era APIs remain, and the custom parser plus checked-in generated lexer files are fragile, but the project remains actively maintained.
sunnypilot is a community fork of comma.ai's openpilot, an open-source driver assistance system (ADAS) designed for real-time operation on dedicated hardware (comma three/4, panda). The codebase implements the full autonomy stack: camera and radar perception, path planning, longitudinal/lateral control, driver monitoring, and localization via Kalman filters. It runs as a set of daemon processes orchestrated by a process manager, communicating through a shared-memory pub/sub messaging layer (msgq) with Cap'n Proto serialization. The system includes a full-featured Raylib-based UI with on-road HUD, settings panels, and an installer, plus cloud connectivity through Athena (remote commands, registration) and the fork-specific Sunnylink (settings backup/restore, telemetry). Beyond the core openpilot functionality, sunnypilot adds numerous extended features: Modular Assistive Driving System (MADS) for configurable steering modes, neural network lateral control (NNLC), map-based speed limit assist using OpenStreetMap data (mapd), intelligent cruise button management, dynamic experimental control, and a model manager that fetches and caches driving model bundles from a remote manifest. The fork maintains its own cereal schema extensions and custom UI layouts for both touch (mici) and big-screen (tizi) hardware variants. The repository includes extensive testing infrastructure: unit tests for most modules, process replay tests that compare outputs against reference logs, longitudinal/lateral maneuver simulations, and CAN bus analysis tools (cabana, replay). It also provides simulation bridges (MetaDrive, joystick) for closed-loop testing. The build system uses SCons for C++ components and uv for Python dependencies, with CI pipelines for model building, release drafting, and route uploads.
librdkafka is a high-performance, production-grade C (and C++) client library for Apache Kafka, developed and maintained by Confluent. It provides full protocol-level support for producing and consuming messages, including advanced features such as exactly-once semantics (idempotent producer, transactions), consumer groups with multiple rebalance protocols (classic and KIP-848), share consumers (KIP-932), and a comprehensive Admin API for cluster management (topics, configs, ACLs, SCRAM credentials). The library is designed for embedding into applications across many languages via bindings (Python, Go, .NET, Rust, etc.) and supports a wide range of authentication mechanisms (SSL, SASL/PLAIN, SCRAM, OAUTHBEARER, GSSAPI) and compression codecs (zstd, LZ4, snappy, gzip). It includes a robust mock cluster for integration testing, a highly configurable configuration system, and extensive unit and integration tests covering hundreds of scenarios. The architecture separates protocol handling, broker transport, partition assignment, and admin operations into modular internal components, while exposing a clean, callback-driven C API and an object-oriented C++ wrapper. The codebase is actively maintained with frequent releases addressing security fixes (CVE tracking), Kafka protocol evolution (e.g., KIP-848, KIP-932), and platform compatibility (Linux, macOS, Windows, s390x). Vendored dependencies like lz4, snappy, cJSON, and nanopb are periodically updated, but some platform-specific #ifdefs and legacy protocol support contribute to moderate technical drift.
Awkward Array is a Python library for manipulating nested, ragged, and mixed-type data structures that do not fit naturally into NumPy's rectangular array model. It is primarily a software library, not a data-research pipeline, though it contains research-oriented studies and benchmarks. The architecture is a Python front-end backed by compiled C++ kernels, with optional integrations for PyArrow, JAX, CuPy, Numba, CUDA, and ROOT. The core data model is built around composable layouts, forms, and types, and operations are dispatched through a high-level function decorator that separates public API from backend-specific implementations.
JavaCPP is a mature, annotation-driven library that provides efficient Java-to-C++ interoperability via JNI. It is not an application but a core infrastructure library used by hundreds of downstream projects (e.g., OpenCV, FFmpeg, TensorFlow bindings) to bridge Java and native C++ code. The system consists of a code generation pipeline (Parser, Generator, Builder) that reads Java annotations and C++ headers to produce JNI wrapper classes, a runtime layer (Loader, Pointer hierarchy) that manages native memory and library loading, and a multidimensional data access layer (Indexer package) optimized for scientific computing. The architecture is modular: build-time code generation (Maven plugin and CLI), runtime library loading with caching and platform detection, and a uniform pointer API with automatic deallocation via PhantomReferences. Key entry points are the Builder class (for build-time code generation) and the Loader class (for runtime library loading). The codebase is largely well-crafted, with reusable patterns like the Indexer factory pattern, PointerScope for deterministic resource management, and annotation-driven configuration. Some core components (Generator, Parser) are acknowledged as complex and messy, reflecting organic growth to handle real-world C++ headers. The repository maintains an extensive test suite and supports a wide range of platforms (Linux, macOS, Windows, Android, iOS, FreeBSD, embedded architectures).
This repository is a large, modular C++ game engine with a fully integrated editor. The engine core provides a world/component architecture, reflection-driven serialization, resource management, a task system, and a render abstraction layer with DirectX 11 and Vulkan backends. Runtime features are delivered as plugins: Jolt physics, FMOD/MiniAudio audio, RmlUi UI, particle effects, animation graphs, AI navigation, procedural generation, terrain, and OpenXR support. The editor is a Qt-based multi-process application: a host editor process communicates with a separate engine process over IPC, mirroring document objects into a live world for preview and manipulation. Asset managers turn imported files such as meshes, textures, skeletons, animation clips, sound events, and UI documents into versioned engine resources. Sample game applications and extensive unit tests demonstrate the runtime API and provide a working baseline for engine consumers. The codebase is production-oriented rather than research-oriented: there are no notebooks, data pipelines, or ML artifacts. Instead, it is an application and framework monorepo with strong engineering discipline visible in its consistent component/manager patterns, plugin registration conventions, and resource lifecycle management. The custom RTTI/reflection system underpins serialization, editor property grids, undo/redo, and scripting, making the engine highly data-driven. However, the code is macro-heavy and some areas, especially editor plugins, repeat near-identical boilerplate patterns across many asset types. The project is actively maintained, with recent commits, CI workflows, and a large third-party dependency set that is mostly bundled in-tree; some bundled libraries and platform-specific paths show moderate drift but not abandonment.
bsnes is a multi-platform Super Nintendo / Super Famicom emulator with an integrated Game Boy core (SameBoy) used for Super Game Boy support and also buildable as a standalone or libretro core. The desktop frontend in target-bsnes loads ROMs, applies BPS/IPS patches, manages save states and rewind, records movies, provides cheat search/editing, maps input, and applies video shaders. The emulation layer in bsnes/sfc is extensive: cycle-accurate CPU/PPU/DSP/SMP, a high-performance alternate PPU, and a broad collection of coprocessor emulations (SA-1, SuperFX, CX4, DSP-1/2/4, SPC7110, SDD1, MSU1, and others). ROM identification is heuristic and normalized into manifests, after which CPU, coprocessor, and PPU threads are synchronized to produce frames, with audio/video/input isolated behind the ruby driver layer.