C++ - Reddit

[std-proposals] Benchmarking using the standard library as a module https://lists.isocpp.org/std-proposals/att-18441/attachment https://redd.it/1to00y0 @r_cpp

pretty good syntax and logic buildup what next like HOW SHOULD I APPROACH DSA ? how should I know that Ive learnt c++ enough so I can start dsa i know java(till array oops) , html , css , js(starting) , SQL , python(till dictionaries list) , started c++ gonna complete soon good catching!! how should I do dsa and practice https://redd.it/1tnhlru @r_cpp

C++ Game Engine Leadwerks 5.1 Beta adds a new deferred renderer, upscaling, terrain-mesh blending...and it runs on a potato https://www.youtube.com/watch?v=XrEhsTXRtRI https://redd.it/1tnh9ol @r_cpp

[https://youtu.be/ulen8XhMeRA](https://youtu.be/ulen8XhMeRA) 2026-04-27 - 2026-05-03 * From 5000ns to 200ns - 5 Modern C++ Techniques Live Demo - Larry Ge - [https://youtu.be/9HqyiTWLENY](https://youtu.be/9HqyiTWLENY) **Audio Developer Conference** 2026-05-18 - 2026-05-24 * Real-Time EEG for Adaptive Music in Games and VR - Marta Rossi - [https://youtu.be/4kNs7cfXNgY](https://youtu.be/4kNs7cfXNgY) * Embedded Musical Signal Processing with Csound 7 - From Microcontrollers to FPGAs - Aman Jagwani - [https://youtu.be/zK0-NVkJd7E](https://youtu.be/zK0-NVkJd7E) * Should Audio Plugins Have “Everything Everywhere All at Once”? - Exploring Modularity, Reusability, and Instrument Identity in Audio Software - Gonçalo Bernardo - [https://youtu.be/XpRfkp5Swfc](https://youtu.be/XpRfkp5Swfc) 2026-05-11 - 2026-05-17 * Sneak Peek at ARA Audio Random Access 3.0 - Embracing Audio Synthesis - Stefan Gretscher - ADC 2025 - [https://youtu.be/a3T1BBIOBH4](https://youtu.be/a3T1BBIOBH4) * Raga as Data - Symbolic Music Representations for Analysis, Visualization, and Audio Tools - Soham Korade - ADCx India 2026 - [https://youtu.be/LPiOnLAbZDA](https://youtu.be/LPiOnLAbZDA) * Cross-Platform Music Software with Rust - Ian Hobson - ADC 2025 - [https://youtu.be/YLPglu2enaE](https://youtu.be/YLPglu2enaE) 2026-05-04 - 2026-05-10 * Continuous QA Testing for Plugins Using AI and Python - Ryan Wardell - [https://youtu.be/w1hLmNPxOV4](https://youtu.be/w1hLmNPxOV4) * Using Kotlin/Compose Multiplatform to Revive a Historic Multiplayer Online Drum Machine - How To Write An Audio App That Runs Almost Everywhere - Phil Burk - [https://youtu.be/8jA6Dg5iqfw](https://youtu.be/8jA6Dg5iqfw) * Converting Source Separation Models to ONNX for Real Time Usage in DJ Software - Anmol Mishra - ADC 2025 - [https://youtu.be/CNs9EgMBocI](https://youtu.be/CNs9EgMBocI) 2026-04-27 - 2026-05-03 * From Paper to Plugin - A Guided Tour of Digital Filters - Ross Chisholm, Joel Ross & James Hallowell - ADC 2025 - [https://youtu.be/QlyWAfRUF30](https://youtu.be/QlyWAfRUF30) * From Idea to Online Sale - The Full Journey of Building an Audio Plugin - Joaquin Saavedra - ADCx Gather 2025 - [https://youtu.be/mJoAArwAmkc](https://youtu.be/mJoAArwAmkc) * Finding OSCar: Electronic and Software Secrets of a Classic Vintage Synth - Ben Supper - ADC 2025 - [https://youtu.be/NbIZEur3h7Q](https://youtu.be/NbIZEur3h7Q) https://redd.it/1tncipk @r_cpp

New C++ Conference Videos Released This Month - May 2026 (Updated To Include Videos Released 2026-05-11 - 2026-05-17) **CppCon** 2026-05-18 - 2026-05-24 * Lightning Talk: How Fast Isn’t You Constexpr? - Hossein GhahramanzadehAnigh - [https://youtu.be/rmfuWQXojtY](https://youtu.be/rmfuWQXojtY) * Lightning Talk: Understanding Data Dependency Chains - Makar Kuznietsov - [https://youtu.be/eMnz158Y0Ok](https://youtu.be/eMnz158Y0Ok) * Lightning Talk: Lambdas, Ranges and trivially\_copyable: Why This Matters for Parallel Algorithms - Ruslan Arutyunyan - [https://youtu.be/9bq1gEw6OzY](https://youtu.be/9bq1gEw6OzY) * Lightning Talk: A C++20 Modules Performance Field Report - Tyler Drake - [https://youtu.be/84qXqMMDS3I](https://youtu.be/84qXqMMDS3I) * Lightning Talk: Crafting CUDA Compatible C++ Code - Jon White - [https://youtu.be/hIx4HpWBoKE](https://youtu.be/hIx4HpWBoKE) 2026-05-11 - 2026-05-17 * Lightning Talk: Reducing Binary Bloat With Thin Archives - Florent Castelli - CppCon 2025 - [https://youtu.be/xs1y0Dl4zZs](https://youtu.be/xs1y0Dl4zZs) * Lightning Talk: Poor Man’s Autocomplete for Template Arguments - Max Sagebaum - CppCon 2025 - [https://youtu.be/DkLSHgxf-Q8](https://youtu.be/DkLSHgxf-Q8) * Lightning Talk: The Classic Missed-Signal! - Gopal Rander - CppCon 2025 - [https://youtu.be/8Ign1X3qkgk](https://youtu.be/8Ign1X3qkgk) * Lightning Talk: Proof Searching in DepC - Raffaele Rossi - CppCon 2025 - [https://youtu.be/sB-mQRsXv1M](https://youtu.be/sB-mQRsXv1M) * Lightning Talk: Bool - Implicitly Dangerous - Jeff Garland - CppCon 2025 - [https://youtu.be/PcerWZRm\_eA](https://youtu.be/PcerWZRm_eA) 2026-05-04 - 2026-05-10 * Lightning Talk: The Type Safe Builder Pattern for C++ - John Stracke - [https://youtu.be/u5EG21amqlM](https://youtu.be/u5EG21amqlM) * Lightning Talk: Back When ChatGpt Was Young And Stupid - Andrei Zissu - [https://youtu.be/q6-RSkQRmw0](https://youtu.be/q6-RSkQRmw0) * Lightning Talk: Learning C++ Through Writing Coding Questions - Christopher DeGuzman - [https://youtu.be/FX63YwZ8OIs](https://youtu.be/FX63YwZ8OIs) * Lightning Talk: Promote Modern C++ Usage With Coding Questions Part 2 - Zhenchao Lin - [https://youtu.be/uTCxKPaPsdM](https://youtu.be/uTCxKPaPsdM) * Lightning Talk: std::move & Spirited Away: When Nameless Objects Walk the Spirited World - Siyu (Alice) Peng - [https://youtu.be/ffEOHVm7b4Y](https://youtu.be/ffEOHVm7b4Y) 2026-04-27 - 2026-05-03 * Lightning Talk: A Pragmatic Approach to C++: Designing, Organizing and Writing Maintainable Code - Oleg Rabaev - [https://youtu.be/re4Oy1IVj-s](https://youtu.be/re4Oy1IVj-s) * Lightning Talk: Causal Inference for Code Writing AI - Matt K Robinson - [https://youtu.be/craQCfj73CI](https://youtu.be/craQCfj73CI) * Lightning Talk: Cut the boilerplate with C++23 deducing\_this - Sarthak Sehgal - [https://youtu.be/o3vjUo2qXNg](https://youtu.be/o3vjUo2qXNg) * Lightning Talk: The Lifecycle of This CMake Lightning Talk - Yannic Staudt - [https://youtu.be/3DqRIxXVfiI](https://youtu.be/3DqRIxXVfiI) * Lightning Talk: Catching Performance Issues at Compile Time - Keith Stockdale - [https://youtu.be/YK8Kwj9okRk](https://youtu.be/YK8Kwj9okRk) **C++Online** 2026-05-18 - 2026-05-24 * Zero-Cost Abstractions in Large C++ Systems - Lessons from OpenJDK’s Barrier Refactoring - Shubhankar Gambhir - [https://youtu.be/4aMaSaFW5Qo](https://youtu.be/4aMaSaFW5Qo) * How Bitcoin Core uses C++ to Maintain Network Agreement - Yuvicc - [https://youtu.be/wCQDX9tg8dw](https://youtu.be/wCQDX9tg8dw) 2026-05-11 - 2026-05-17 * RPC with RAII and C++ Coroutines - Edward Boggis-Rolfe - C++Online 2026 - [https://youtu.be/JjEcSONwhHE](https://youtu.be/JjEcSONwhHE) * C++ for High Performance Web Application Backends - Uzochukwu Ochogu - C++Online 2026 - [https://youtu.be/ulen8XhMeRA](https://youtu.be/ulen8XhMeRA) 2026-05-04 - 2026-05-10 * MayaFlux: Real-Time Audio-Graphics Coordination in C++20 (Coroutines, Lock-Free) - Ranjith Hegde - [https://youtu.be/\_qZvFNCYQ74](https://youtu.be/_qZvFNCYQ74) * C++ for High Performance Web Application Backends - Uzochukwu Ochogu -

New C++ Conference Videos Released This Month - May 2026 (Updated To Include Videos Released 2026-05-11 - 2026-05-17) CppCon 2026-05-18 - 2026-05-24 Lightning Talk: How Fast Isn’t You Constexpr? - Hossein GhahramanzadehAnigh - [https://youtu.be/rmfuWQXojtY](https://youtu.be/rmfuWQXojtY) Lightning Talk: Understanding Data Dependency Chains - Makar Kuznietsov - https://youtu.be/eMnz158Y0Ok Lightning Talk: Lambdas, Ranges and trivially\_copyable: Why This Matters for Parallel Algorithms - Ruslan Arutyunyan - [https://youtu.be/9bq1gEw6OzY](https://youtu.be/9bq1gEw6OzY) Lightning Talk: A C++20 Modules Performance Field Report - Tyler Drake - https://youtu.be/84qXqMMDS3I Lightning Talk: Crafting CUDA Compatible C++ Code - Jon White - [https://youtu.be/hIx4HpWBoKE](https://youtu.be/hIx4HpWBoKE) 2026-05-11 - 2026-05-17 Lightning Talk: Reducing Binary Bloat With Thin Archives - Florent Castelli - CppCon 2025 - https://youtu.be/xs1y0Dl4zZs Lightning Talk: Poor Man’s Autocomplete for Template Arguments - Max Sagebaum - CppCon 2025 - [https://youtu.be/DkLSHgxf-Q8](https://youtu.be/DkLSHgxf-Q8) Lightning Talk: The Classic Missed-Signal! - Gopal Rander - CppCon 2025 - https://youtu.be/8Ign1X3qkgk Lightning Talk: Proof Searching in DepC - Raffaele Rossi - CppCon 2025 - [https://youtu.be/sB-mQRsXv1M](https://youtu.be/sB-mQRsXv1M) Lightning Talk: Bool - Implicitly Dangerous - Jeff Garland - CppCon 2025 - https://youtu.be/PcerWZRm\_eA 2026-05-04 - 2026-05-10 Lightning Talk: The Type Safe Builder Pattern for C++ - John Stracke - [https://youtu.be/u5EG21amqlM](https://youtu.be/u5EG21amqlM) Lightning Talk: Back When ChatGpt Was Young And Stupid - Andrei Zissu - https://youtu.be/q6-RSkQRmw0 Lightning Talk: Learning C++ Through Writing Coding Questions - Christopher DeGuzman - [https://youtu.be/FX63YwZ8OIs](https://youtu.be/FX63YwZ8OIs) Lightning Talk: Promote Modern C++ Usage With Coding Questions Part 2 - Zhenchao Lin - https://youtu.be/uTCxKPaPsdM Lightning Talk: std::move & Spirited Away: When Nameless Objects Walk the Spirited World - Siyu (Alice) Peng - [https://youtu.be/ffEOHVm7b4Y](https://youtu.be/ffEOHVm7b4Y) 2026-04-27 - 2026-05-03 Lightning Talk: A Pragmatic Approach to C++: Designing, Organizing and Writing Maintainable Code - Oleg Rabaev - https://youtu.be/re4Oy1IVj-s Lightning Talk: Causal Inference for Code Writing AI - Matt K Robinson - [https://youtu.be/craQCfj73CI](https://youtu.be/craQCfj73CI) Lightning Talk: Cut the boilerplate with C++23 deducing_this - Sarthak Sehgal - https://youtu.be/o3vjUo2qXNg Lightning Talk: The Lifecycle of This CMake Lightning Talk - Yannic Staudt - [https://youtu.be/3DqRIxXVfiI](https://youtu.be/3DqRIxXVfiI) Lightning Talk: Catching Performance Issues at Compile Time - Keith Stockdale - https://youtu.be/YK8Kwj9okRk C++Online 2026-05-18 - 2026-05-24 Zero-Cost Abstractions in Large C++ Systems - Lessons from OpenJDK’s Barrier Refactoring - Shubhankar Gambhir - [https://youtu.be/4aMaSaFW5Qo](https://youtu.be/4aMaSaFW5Qo) How Bitcoin Core uses C++ to Maintain Network Agreement - Yuvicc - https://youtu.be/wCQDX9tg8dw 2026-05-11 - 2026-05-17 RPC with RAII and C++ Coroutines - Edward Boggis-Rolfe - C++Online 2026 - [https://youtu.be/JjEcSONwhHE](https://youtu.be/JjEcSONwhHE) C++ for High Performance Web Application Backends - Uzochukwu Ochogu - C++Online 2026 - https://youtu.be/ulen8XhMeRA 2026-05-04 - 2026-05-10 MayaFlux: Real-Time Audio-Graphics Coordination in C++20 (Coroutines, Lock-Free) - Ranjith Hegde - [https://youtu.be/\_qZvFNCYQ74](https://youtu.be/_qZvFNCYQ74) C++ for High Performance Web Application Backends - Uzochukwu Ochogu -

wrote a small http server in c++ that searches youtube video transcripts stored in sqlite and the binary is 2.1MB i work at a robotics company and we have about 160 youtube videos. recorded design reviews, firmware walkthroughs, test procedure demos, safety training recordings, conference presentations. they're all in a shared google drive folder as links and the only way to find anything is scrolling through filenames like "DR_2024_03_14.txt" which tells you literally nothing about what was discussed. i wanted a fast search tool with minimal dependencies so i wrote it in c++. the server uses cpp-httplib which is a single header file for an http server. one GET endpoint for the search query, one for serving the static html page. the html is embedded as a string literal in the source so the binary is completely self-contained. no external files to deploy. the database is sqlite with FTS5 for full text search. i have a metadata table with video_id, title, date, presenter, tags, and youtube_url, and an FTS5 virtual table that indexes the transcript text. the search runs a MATCH query on the FTS5 table and uses snippet() for the excerpt with the match highlighted. joined back to the metadata table for the video info. for pulling the transcripts i wrote a separate ingestion tool. it reads urls from a text file, calls transcript api for each one using libcurl, parses the json with nlohmann/json, and inserts into sqlite. the ingestion tool is about 150 lines. the server is about 200 lines. the search query returns in under 2ms for 160 transcripts. i measured it with std::chrono out of habit and then realized it was pointless because the bottleneck is the network round trip not the query. the FTS5 index makes the sqlite part basically free. the build uses cmake. three dependencies: cpp-httplib (header only, vendored), nlohmann/json (header only, vendored), and sqlite3 (system library). the final binary is 2.1MB statically linked. i copied it to our internal tools server along with the sqlite database file and that was the deployment. added a systemd unit file and it's been running for 3 months. memory usage at idle is about 4MB. under load with a few concurrent searches it barely moves. the sqlite database with 160 transcripts is about 45MB on disk. the whole thing fits on basically any machine. the team uses it before design reviews to search for what was discussed in previous reviews. the firmware engineers search for specific peripheral names to find the walkthrough where someone demonstrated the configuration. one of the test engineers told me she searches for failure mode descriptions from past test reviews which is a use case i hadn't thought of. the part i like about this project is that it'll run unchanged for years. no package manager updates, no runtime version changes, no dependency hell. it's a binary and a database file. if the server dies i copy two files to a new machine and start it. https://redd.it/1tn5p38 @r_cpp

Optimizing a real-time C++17 terminal audio visualizer, what am I missing? I've been building spectrum, a terminal audio visualizer that hooks into WASAPI and runs FFT analysis via FFTW3. Took heavy inspiration from Winamp's spectral analyzer for the peak physics and decay behavior. Current pipeline: \- 2400-sample Hann-windowed FFT with 95% window overlap (120-sample hop at 48kHz) \- Producer-consumer architecture, mutex-guarded shared buffers between capture and render thread \- AGC with rolling normalization + gamma contrast for dynamic range \- Logarithmic frequency binning (20Hz–16kHz) with perceptual tilt It runs at 60 FPS with <5% CPU. What would you optimize next? I'm hitting a point of diminishing returns (especially with the bar height logic, and what frequencies should and should not be displayed) and would love some architectural feedback. Considering: \- Lock-free ring buffer to replace the mutex \- WASAPI exclusive mode for lower latency capture GitHub: github.com/majockbim/spectrum https://redd.it/1tmvr96 @r_cpp

Building a Host-Tuned GCC to Make GCC Compile Faster https://peter0x44.github.io/posts/super-gcc/ https://redd.it/1tmw04p @r_cpp

between containers. The proof for this can be seen in my msvc results, which have worse hive insertion, erasure and post-erasure iteration performance for the 48-byte ("small struct") isolated benchmarks than hub, but are still faster than hub in the general use (unordered modification) tests, which also store 48-byte structs and perform insertion, erasure and iteration in the same container instance over time. Only at the highest insert/erase-to-iteration ratio (10% of container size inserted/erased per-iteration) does hub perform better. This is not an anomoly; the same pattern is visible in clang and gcc, where isolated benchmarks of insert/erase are slower in hive with post-erasure iteration only 1% faster than hub, but hive is still 8% faster for all the lower churn ratios in the unordered modification benchmarks. * Insert is slower on average for hive under msvc except for large types, slower for clang except for large types, and slower for gcc except for large numbers of large types. * Iteration is generally faster across compilers for hive, however it is slower for 64-bit types under clang and small structs under msvc, and there is variation based on the number of elements. * Memory use of hub varies between 96% and 50% of the usage of hive (but only for current implementation obviously). The main thing to take away from all this is do your own benchmarks for your own use-case. You can use the guidelines above, but results may be very different on, say, a snapdragon processor. Also as mentioned, not all scenarios suit visitation. Always good to see new variations and experiments coming out! :) https://redd.it/1tmr7k2 @r_cpp

A brief-ish (author-consulted) guide for when to use boost::hub over plf::hive/colony, with benchmarks std::hive/plf::hive author here, I recently found out about boost::hub via a friend, ran my own benchmarks, and contacted the author, Joaquin. We've been talking over the past week and while we have some disagreements (more here: https://plflib.org/blog.htm#hive\_vs\_hub), we generally agree on the following and we've learned a bit from each other as well. Please bear in mind that the following assumptions only apply to the current implementations of plf::hive and boost::hub, not future implementations nor other std::hive implementations. As an example, myself and another have been working on a memory-reduced implementation of hive since august '25 (\~1.2bits skipfield per element average) and we dont know what the performance results will be for that yet. That aside, the following is true (when I say 'hive' below I mean plf::hive, and same conclusions apply for plf::colony since it's largely the same code): * Hub is generally faster overall for smaller types, for very large types hive is typically better. * Insert is generally faster for hub except for large types. * Erase is faster for hub. * Results vary a little by compiler, but in tests which measure the effect of insertion and erasure on iteration over time using 48-byte structs, hive is faster except for high churn ratios. Specifically hub tends to be better once the ratio is around or above a number of elements equal to 5% of the container size being inserted/erased for every single iteration pass over all elements. However for very small elements the ratio will likely shift downward (in hub's favour) and for very large elements the ratio will likely shift upwards (in hive's favour). * get_iterator() performs worse when maximum block capacities are smaller, as there are more blocks to check before the pointer location is found, so hub performs much worse than hive (when default-or-larger max block sizes are used with hive) here. However the results would be the same in hive if a user were to limit the block capacities to 64-elements max themselves. * Sorting is faster with hub except for large numbers of large types - we both need to do some work here. * According to Joaquin's benchmarks hive seems to be a lot faster than hub for 32-bit executables, but I haven't benchmarked this. I haven't mentioned visitation yet, but it's cool! It's a technique which can be applied to any semi-contiguous container including deques, unrolled lists like plf::list, colony, segmented vectors and potentially as a (non-compliant) extension for hive. Basically it's iteration + pre-fetching, which only the container can do because it knows when the next block begins during iteration. It's not something you want the container to do during iteration normally because it doesn't know how the user is using the container at that point. However, it is limiting in how you can use it - basically it's good if you want to do the same thing to a range of elements, but it doesn't work with the standard library routines such as rangesv3, because that all takes iterators. You also need to be careful with it if your code or libraries you use do pre-fetching internally. If you can use the visit* techniques in your particular use-case may shift the balance of the above in hub's favour, except for large elements, where insertion performance can be better with hive, depending on the compiler. But I will probably implement the same techniques myself soon, for colony. From my benchmarks across clang, gcc and msvc (https://plflib.org/benchmarks\_hive\_vs\_hub.htm) I'll also add the following conclusions, though will likely be some variance based on CPU: * Isolated benchmarks of insert, erase and iteration, are not sufficient to measure how a hive or hive-like container will perform during iteration over time, as erasures and reserved blocks stack up, because handling of the latter differs

I'm a fresh graduate earning around $7100/month. I'm currently building strong foundations in C++, desktop apps, and web development. Long term, I'm thinking about freelancing from home. Realistically, after becoming skilled, how much can software freelancers make from projects? https://redd.it/1tmhjaq @r_cpp

Sorry everyone, I'm new to Reddit and still learning how communities work here. I didn't mean to spam or repeat questions. I genuinely enjoy learning from your experiences and advice, and I appreciate everyone who takes the time to reply. https://redd.it/1tmhx77 @r_cpp

ycetl — a header-only library for building data structures at constexpr time and using them at runtime (C++20, no C++26 needed) Hi r/cpp, I've been working on ycetl, a small header-only library that takes on the "build a data structure at compile time, ship it as a runtime constant" problem. The core trick is a multi-type memory backbone: instead of a std::byte* arena that requires void* → T* casts (forbidden in constant evaluation in C++20/23, only legal in C++26 via P2738), you enumerate the type set up front and the allocator becomes a tuple<Backend<T>...> indexed at compile time. Every allocation stays typed end-to-end. No erasure anywhere. On top of that, the usual STL shapes — dynamic_array (vector-shaped), flat-sorted set/map, open-addressing unordered_set/unordered_map, the multi* variants, stack, priority_queue, span, bitset, unique_ptr, shared_ptr + weak_ptr. Every container is tested under static_assert(lambda()) and at runtime, with the same code. Small taste — sieve at constexpr time, result baked into .rodata: constexpr auto compute_primes() { primes_result<32> out{}; ycetl::default_memory<bool, std::pair<int,int>> mem; // working memory auto sieve = mem.allocate<bool>(101); auto records = mem.allocate<std::pair<int,int>>(32); // ... sieve + collect into records + copy into out ... return out; // result memory } constexpr auto baked = compute_primes(); static_assert(baked.records[24\].first == 97); There's also a worked example that drives libclang against dawn/webgpu.h and emits both a Python ctypes binding and a constexpr C++ tree of the same API — same source, two consumers. Where it sits next to C++26. The "less-transient constexpr allocations" work (P3032) + the void* cast (P2738) tackle the same problem from the opposite direction: make the compiler smart enough to promote std::vector-shaped allocations to static storage. ycetl is the explicit-control side of that trade — you write the type set and the result-shape, in exchange you get a transparent layout, no void* round-trips, no proof-obligation on the compiler, and it runs on shipping GCC 12+ / Clang 16+ today. There's a section in the README laying both sides out honestly; I'd genuinely like to hear which trade people here prefer. Honest about gaps: a few headers from an earlier design (vector.hpp, list.hpp, basic_string.hpp) haven't been ported and their tests are gated off. No real deque/queue yet. Single-threaded by design the smart-pointers use non-atomic counts. Repo: https://github.com/zokrezyl/ycetl Critique welcome — especially from anyone who's tried this kind of design and hit walls I haven't yet. https://redd.it/1tmdbr7 @r_cpp

Hello everyone. I’m learning C++ seriously and want to work as a freelancer in the future after building strong programming and SQL skills. Is learning C++ still a good investment nowadays? Also, what skills should I combine with C++ to improve freelancing opportunities? Thanks. https://redd.it/1tmbe9o @r_cpp

I’m learning C++ and cybersecurity, and I’m curious: are there any famous hacking stories where C++ was used to build tools, malware, exploits, or security research software? Real examples make learning more exciting for me. &#x200B; https://redd.it/1tm9i5k @r_cpp

detailed output from a single area. ### Performance Nova has been benchmarked against several popular C++ logging libraries, including Quill and spdlog, using: * multiple thread counts * fixed queue sizes * sustained throughput scenarios * guaranteed-delivery latency tests * both real file sinks and counting sinks to isolate I/O overhead The benchmarks intentionally normalize queue sizing and backend threading models to avoid structurally advantaging any particular library configuration. Results varied by workload, but several patterns consistently emerged: * Nova performed particularly well in guaranteed-delivery scenarios and bounded-memory configurations * Nova's synchronized sink significantly outperformed comparable synchronous configurations from other libraries * Nova's async backend (using a no-I/O counting sink) demonstrated competitive throughput across thread counts while maintaining zero per-record heap allocation throughout * Quill achieved extremely high front-end enqueue throughput, but with substantial drop rates under sustained overload conditions * spdlog async showed performance degradation under heavy multi-threaded workloads While Nova does not always achieve the highest theoretical front-end enqueue rate, it performed extremely competitively across a broad range of realistic workloads, especially where deterministic behavior and bounded memory usage are important. Full benchmark methodology and raw benchmark data are available in the repository. ### Design Philosophy | Principle | Description | |---|---| | Domain-based routing | Logging should reflect application structure rather than forcing subsystems into global severity categories | | Deterministic behavior | No heap allocation, exceptions, or RTTI by design - heap usage is explicitly documented where it exists (such as in a small number of convenience sinks) and avoided everywhere else across Nova core, Nova Extras, and Flare | | Explicit tradeoffs | Buffer and queue sizes, synchronous vs asynchronous delivery, blocking, and fan-out behavior should be visible and configurable | | Compile-time configuration | Logging configuration should be resolved at compile time whenever practical | | Production-oriented design | Optimize for sustained, realistic workloads and operational predictability | | Modern C++ | Use modern language features without introducing unnecessary complexity or heavy dependencies | | Performance-conscious design | Logging overhead should remain predictable and low, especially in latency-sensitive and multi-threaded systems | ### Current Status & Feedback The initial release is now available at the repository linked above. I am still actively working on improving the library with additional features such as: * additional sinks/backends * packaging and integration polish * binary logging I would appreciate feedback on any aspects of Nova (e.g. integration experience, cross-platform/compiler issues, feature requests). If you try Nova in a project, I’d love to hear how it performs and where it can improve. Thanks for reading. https://redd.it/1tm0ihy @r_cpp

Domain-Based C++ Logging With Nova ### Introducing Nova - A Deterministic C++ Logging Library With Domain-Based Routing Repository: https://github.com/kmac-13/nova/ Benchmarks: https://github.com/kmac-13/nova/blob/main/docs/BENCHMARKS.md I am pleased to announce the initial release of **Nova** - a modern C++ logging library focused on deterministic behavior, compile-time configurability, and flexible domain-based routing for systems ranging from hosted platforms down to bare-metal and safety-critical environments. ### Why Another Logging Library? There are already several quality C++ logging libraries available. However, most logging libraries organize routing and filtering around severity levels and rely on global logger configuration or runtime string-based logging categories. Engineers are often forced to encode subsystem behavior into a limited set of severity levels while also considering which thresholds will be enabled in production. This also leads to situations where enabling debug logging for one subsystem effectively requires enabling debug logging across unrelated areas of the application. Nova instead treats logging domains as compile-time types, allowing logging configuration and routing to directly reflect application structure rather than forcing subsystems into global severity categories. Domains can represent subsystems, modules, interfaces, classes, libraries, or any other domain-specific concept, and each domain can be independently enabled, disabled, or routed without reliance on shared global configuration. Because domains are independent types rather than shared string identifiers, libraries can define their own logging domains without interfering with application or third-party logging configuration. * type-defined logging domains - log against subsystems, modules, classes, libraries, or any other concept * compile-time elimination of disabled domains - language-guaranteed in C++17, optimiser-dependent in C++11/14 * compile-time routing - avoids reliance on global logger registries or shared runtime configuration Additional goals of the library include: * simple pipeline and extensible API * deterministic behavior - no heap, no exceptions, no RTTI * support for platforms ranging from hosted systems down to bare-metal * fast enough for demanding real-time and multithreaded workloads Nova also includes Flare, an async-signal-safe crash and forensic logging component that writes structured diagnostic records directly to disk from signal handlers - without heap allocation, locks, or non-signal-safe C++ runtime features. ### Example cpp #include <nova.h> // define a domain (can be any type) struct MotionPlanner {}; // configure the domain with a name (MOTION), enabled state (true), and clock type (steadyNanosecs) NOVA_LOGGER_TRAITS( MotionPlanner, MOTION, true, kmac::nova::TimestampHelper::steadyNanosecs ); int main() { // configure motion planner sink as mpSink ... // bind the mpSink to the MotionPlanner logging domain kmac::nova::ScopedConfigurator config; config.bind< MotionPlanner >( &mpSink ); // log NOVA_LOG( MotionPlanner ) << "Planning trajectory..."; } Here we can see that the `MotionPlanner` domain is defined, the traits for the domain are configured, a target sink is bound to the domain, and logging is performed. In this example, the domain is a simple, empty struct, but a domain can be any type, including interface, abstract, or concrete classes. A domain can even be a specific class, and logging can be limited to the scope of that class. Using types as logging domains enables compile-time routing, strong subsystem separation, and per-domain configuration and enablement. Disabled domains can be eliminated entirely by the compiler, and type names prevent the silent runtime failures that string-based routing can introduce. Additionally, per-domain control means that enabling verbose logging for one subsystem has no effect on any other - there is no shared severity threshold to raise or lower across the entire application just to see

Building a c++ cross platform UI library Flux ui is c++ UI library in which same application code works on Windows, Linux and Android. Uses gdi+ for Windows, cairo for Android and nanovg for android. Please and give feedback. https://github.com/HeyItsBablu/flux.git https://redd.it/1tm02cl @r_cpp

MBC++ An Open Source Multibody Dynamics Library Hello, I am happy to provide a Multibody Dynamics library for the topic's enthusiasts. It is created taking the recent advancements in MBD. You can find the details on the github page of the library. Any commits(next step is to include GPU solving) are highly wellcome. Thank you in advance. https://github.com/burakertr/MBCPlusPlus https://redd.it/1tly88y @r_cpp