ru
Feedback
C++ - Reddit

C++ - Reddit

Открыть в Telegram

Stay up-to-date with everything C++! Content directly fetched from the subreddit just for you. Join our group for discussions : @programminginc Powered by : @r_channels

Больше
228
Подписчики
Нет данных24 часа
Нет данных7 дней
Нет данных30 день
Архив постов

Learn Task-Parallel Programming using Taskflow and Modern C++ -- Video Series https://www.youtube.com/playlist?list=PLyCypiNN-fjlSioqrEkL4QsKZBawA5Zk1 https://redd.it/1r0f7y6 @r_cpp

MigrationManager::GetInstance(); manager.CreateMigrationHistory(); size_t applied = manager.ApplyPendingMigrations(); ``` Supports rollbacks, dry-run preview, checksum verification, and distributed locking for safe concurrent deployments. --- ## Backup & Restore Full database backup/restore with progress reporting: ```cpp #include <Lightweight/SqlBackup.hpp> // Backup to compressed archive (multi-threaded) SqlBackup::Backup( "backup.zip", connectionString, 4, // concurrent workers progressManager, "", // schema "*", // table filter (glob) {}, // retry settings { .method = CompressionMethod::Zstd, .level = 6 } ); // Restore SqlBackup::Restore("backup.zip", connectionString, 4, progressManager); ``` Preserves indexes, foreign keys (including composite), and supports table filtering. --- ## Supported Databases - Microsoft SQL Server - PostgreSQL - SQLite3 Works anywhere ODBC works (Windows, Linux, macOS). --- ## What's Next We're actively developing and would love feedback. The library is production-ready for our use cases, but we're always looking to improve the API and add features. We also consider abstracting away ODBC such that it could support non-ODBC databases like SQLite3 directly without the ODBC layer. That's a longer-term goal, but definitely a goal. We currently focus on SQL tooling (migrations and backup/restore) as both are quite young additions that are still evolving. Questions and PRs welcome! https://redd.it/1r0co80 @r_cpp

Lightweight: Almost-zero-overhead C++23 SQL library with DataMapper ORM, migrations, and backup/restore Hi r/cpp, We're excited to share **Lightweight**, a modern C++23 ODBC wrapper we've been building to solve our need for high-level SQL access without runtime overhead. **Philosophy:** Down-to-zero runtime cost is mandatory requirement. We reduce high-level API into near-raw ODBC calls during compilation by using compile-time reflection techniques. **GitHub:** https://github.com/LASTRADA-Software/Lightweight/ **Docs:** https://lastrada-software.github.io/Lightweight/ --- ## Low-Level API: SqlStatement & SqlConnection For those who want direct control, the core API is clean and minimal: ```cpp auto stmt = SqlStatement {}; // Direct execution stmt.ExecuteDirect("SELECT * FROM Users WHERE age > 21"); while (stmt.FetchRow()) std::println("{}: {}", stmt.GetColumn<int>(1), stmt.GetColumn<std::string>(2)); // Prepared statements with type-safe binding stmt.Prepare(R"(INSERT INTO Employees (name, department, salary) VALUES (?, ?, ?))"); stmt.Execute("Alice", "Engineering", 85'000); stmt.Execute("Bob", "Sales", 72'000); // Output column binding std::string name(50, '\0'); int salary {}; stmt.Prepare("SELECT name, salary FROM Employees WHERE id = ?"); stmt.BindOutputColumns(&name, &salary); stmt.Execute(42); ``` ### Bulk Insertions Insert thousands of rows efficiently with a single call: ```cpp stmt.Prepare(R"(INSERT INTO Employees (name, department, salary) VALUES (?, ?, ?))"); // Works with mixed container types auto names = std::array { "Alice"sv, "Bob"sv, "Charlie"sv }; auto depts = std::list { "Eng"sv, "Sales"sv, "Ops"sv }; // even non-contiguous! unsigned salaries[] = { 85'000, 72'000, 68'000 }; stmt.ExecuteBatch(names, depts, salaries); // Single ODBC batch call ``` Three batch methods for different scenarios: - `ExecuteBatchNative()` - Fastest, requires contiguous memory - `ExecuteBatchSoft()` - Works with any range (std::list, etc.) - `ExecuteBatch()` - Auto-selects the best method --- ## DataMapper: High-Level ORM Define your schema as C++ structs, and the DataMapper handles the rest: ```cpp struct Person { Field<SqlGuid, PrimaryKey::AutoAssign> id; Field<SqlAnsiString<25>> name; Field<bool> is_active { true }; Field<std::optional<int>> age; }; void Example(DataMapper& dm) { dm.CreateTable<Person>(); auto person = Person { .name = "John", .is_active = true, .age = 30 }; dm.Create(person); // INSERT - id auto-assigned person.age = 31; dm.Update(person); // UPDATE // Fluent query API auto active = dm.Query<Person>() .Where(FieldNameOf<&Person::is_active>, "=", true) .OrderBy(FieldNameOf<&Person::name>) .All(); dm.Delete(person); // DELETE } ``` --- ## Relationships with Lazy Loading ```cpp struct User { Field<SqlGuid, PrimaryKey::AutoAssign> id; Field<SqlAnsiString<30>> name; HasMany<Email> emails; // One-to-many }; struct Email { Field<SqlGuid, PrimaryKey::AutoAssign> id; Field<SqlAnsiString<100>> address; BelongsTo<&User::id, SqlRealName{"user_id"}> user; // <--- Foreign key relation }; // Navigate relationships naturally auto email = dm.QuerySingle<Email>(emailId).value(); auto userName = email.user->name; // Lazy-loaded // Or iterate user.emails.Each([](Email const& e) { std::println("Email: {}", e.address.Value()); }); ``` Also supports `HasManyThrough` for many-to-many relationships via join tables. --- ## Database Migrations in Pure C++ No external tools or SQL files - define migrations as C++ code: ```cpp LIGHTWEIGHT_SQL_MIGRATION(20240115120000, "create users table") { using namespace SqlColumnTypeDefinitions; plan.CreateTable("users") .PrimaryKey("id", Guid()) .RequiredColumn("name", Varchar(50)).Unique().Index() .RequiredColumn("email", Varchar(100)).Unique() .Column("password", Varchar(100)) .Timestamps(); // created_at, updated_at } // Apply pending migrations auto& manager =

What coding style would make you adopt a C++ library? I maintain https://github.com/aregtech/areg-sdk, a C++ framework for building distributed service-oriented systems. Think of it as a lightweight alternative to gRPC/DDS for cases where your services need to work identically across threads, processes, and networked machines. Same code, zero changes, just reconfigure the deployment. We're planning a major modernization pass (targeting min C++17) and kicked off a https://github.com/aregtech/areg-sdk/discussions/669 in the repo. Before we commit to breaking changes, I'd love to hear what the community actually prefers. Quick context on what we have at the moment: PascalCase types, camelCase methods, mPascalCase members Mixture of const char* and std::string_view in public APIs Mixture of plain and smart pointers Macros for logging scopes, code visibility, and code generator C++17 minimum required version What we're considering: Modernizing APIs to use std::string_view, constexpr, and concepts (if we go for C++20) Smart pointers where applicable Switching to snake_case to align with STL (or maybe staying camelCase?) Reducing macro usage where C++17/C++20 features can replace them Two-parameter logging macros to fix path separator ambiguity (if switch camel_case) The real question: When you evaluate a C++ library, what makes you close the tab? Is it the naming convention / coding style? The API modernity? Documentation? Something else entirely? Some modernizations are crystal clear. Others are not. For example, is it worth switching to C++20, or will that lock out embedded developers (embedded Linux, Zephyr RTOS)? Which version of C++ are you using in your projects, and would you be willing to adopt a library that requires C++20? If you're curious about the architecture: it's an event-driven, fire-and-forget model where services communicate through auto-generated proxies. The framework handles serialization, message routing, and thread-safe dispatch. A service consumer calls requestXxx(param), the provider implements requestXxx(param) and calls responseXxx(result). All routing is automatic. The same code works for inter-thread, IPC, and network communication, where the transport remains transparent. Would love honest feedback. We're a small project trying to do things right. https://redd.it/1r02j37 @r_cpp

to each client's send buffer via ZeroCopyOutputStream → N serializations * Optimized: serialize once to a lightweight buffer, then memcpy to each client's send buffer &#8203; // Before: O(N) serializations for (auto& client : clients) { client->Send(message); // serializes each time } // After: O(1) serialization + O(N) memcpy LightWeightSendStream stream; message.SerializeToZeroCopyStream(&stream); for (auto& client : clients) { client->Send(stream); // fast memcpy only } # 7. Debugging memory corruption with hardware breakpoints We had a bug where a 192-byte lambda capture was being corrupted at byte offset 136 — intermittently, in production only. Traditional debugging was useless. Our approach: 1. **Canary message:** Send a dummy message of the same size before the real one. The dummy gets corrupted instead, and we detect it with a known byte pattern. 2. **Hardware breakpoints:** Use CPU debug registers (DR0–DR7) to trigger on write access to the predicted corruption address at runtime. &#8203; CONTEXT context; context.Dr0 = (DWORD_PTR)(target_address); // address to watch context.Dr7 |= (1 << 0); // enable Dr0 context.Dr7 |= (1 << 16); // write access context.Dr7 |= (3 << 18); // 4 bytes SetThreadContext(thread_handle, &context); Combined with `AddVectoredExceptionHandler` and `CaptureStackBackTrace`, this lets us catch the exact call stack that writes to a specific memory address — without attaching a debugger. **Limitation:** Hardware breakpoints are per-thread (set via thread context), so you only catch corruption if the writing thread is the one with the breakpoint installed. # 8. Async stack traces for crash dump analysis With deeply nested async calls (Post → Promise → Task), traditional call stacks are useless — you just see the event loop scheduler. We implemented [async stack traces inspired by Folly](https://developers.facebook.com/blog/post/2021/09/16/async-stack-traces-folly-Introduction/) and Visual Studio Natvis visualizations to reconstruct the logical async call chain in crash dumps. For unhandled exceptions in coroutines, we store the source location in a static variable so crash dumps always show where the coroutine was last suspended — bridging the gap between the physical stack (scheduler) and the logical stack (your actual code). # 9. Modern C++ features we adopted (and pre-implemented) We use C++20 fully (Concepts, Ranges, Coroutines — but not Modules yet, VS support was insufficient at launch). We also pre-implemented several C++23/26 features: * `std::expected` (C++23) — error handling without exceptions * `std::ranges::to`, `enumerate`, `zip`, `cartesian_product` (C++23) * `std::function_ref` (C++26) — lightweight non-owning callable wrapper, zero allocation * `std::ranges::concat_view` (C++26) We tried to adopt C++20 Modules in early 2023 but had to stop due to incomplete VS implementation. We're preparing to retry now with VS 2022 updates. We're excited about C++26's Compile-time Reflection, `hazard_pointer`/RCU, Execution control library, and Contracts. Happy to answer questions about any of these topics. After 2 years of live service with millions of players, the biggest takeaway is: **the bugs that matter in production are almost never the ones you test for.** https://redd.it/1qzzdjf @r_cpp

process. Each actor has its own message queue and processes messages sequentially, scheduled across a thread pool. The key performance principle: **distribute work across many actors so all 72 cores stay busy.** But in live service, we hit an unexpected bottleneck: **field bosses.** The game originally designed all zones as PvP-enabled, so field bosses were meant to be PvPvE encounters — players would fight each other while fighting the boss, naturally distributing load. But a late design change introduced "peace mode" (no PvP). Result: 2000+ players stood still in one spot, spamming skills at a single NPC. That NPC's actor became a Monolithic Actor — hundreds of message producers, one sequential consumer. Its message queue grew faster than one core could drain it, while the other 71 cores sat idle waiting. Our general strategies for preventing singleton actor bottlenecks: 1. **Split by purpose** (ClientRepo, GuildRepo, SessionRepo — never one god-repository) 2. **Shard by hash** (N actors with modulo routing for request-heavy workloads) 3. **Per-thread read copies** (for read-heavy data like spatial indexes — reads are lock-free, only writes go through the actor) For the field boss specifically, we added **MulticastProxyActors**. Profiling showed the dominant cost inside the boss actor was broadcasting packets to hundreds of nearby players (N² fan-out). The boss now delegates packet broadcasting to a pool of proxy actors, keeping its own queue focused on game logic. # 4. TCP Bandwidth-Delay Product bit us in production During a beta test hosted on AWS in a distant region, players with high-latency connections (\~200ms RTT) kept disconnecting during large-scale battles. The symptom: throughput capped at \~50 KB/sec. After ruling out client issues with a headless client test, we traced the problem to our network layer using Windows Registered I/O (RIO). The send buffer was sized at only 8KB. Since sends complete only after the data is ACKed, with 200ms RTT the pipeline stalls: **8KB / 200ms = 40 KB/sec maximum throughput.** The fix was simply increasing the RIO send buffer size. That's it — a one-line config change. But it took days of investigation across network, client, and server teams to find it. The deeper lesson was: **understand TCP fundamentals (BDP = Bandwidth × RTT) when sizing your I/O buffers**, especially when deploying to regions with higher latency than your test environment. # 5. C++20 Coroutines: powerful but deceptive We adopted C++20 coroutines (`co_await`) alongside our existing Promise-based async. Coroutines are great for readability, but they create a **dangerous illusion of synchronous code.** Task<void> OnRecvSellWeapon() { const Item* weapon = pc->GetWeapon(id); if (!pc->CanSell(weapon)) co_return; co_await *shop_npc; // ← context switch! if (!shop_npc->CanBuy(weapon)) co_return; // ← weapon may be deleted! co_await *pc; // ← context switch! pc->AddGold(weapon->price); // ← weapon may be deleted! } The code reads like a synchronous function, but each `co_await` switches to a different actor's context. Between suspension points, **any pointer or reference may have been invalidated** — other actors keep running. Developers naturally forget this because the code *looks* sequential. **The coroutine paradox:** * Pro: "Reads like synchronous code" * Con: "Developers forget it's asynchronous" Solutions: acquire ownership (`unique_ptr`), re-validate after resume, or copy values before suspension points. We follow C++ Core Guidelines strictly: [CP.51](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cpcoro-coroutines) (no capturing lambda coroutines), CP.52 (no locks across suspension), CP.53 (no reference params to coroutines). # 6. Protobuf serialization: serialize once, copy many For multicast packets (same message to hundreds of players), we learned that: * **Serialization cost >> memory copy cost** * Initial approach: serialize directly

Lessons learned from 2 years of operating a C++ MMO game server in production I've been working as a server team lead and technical director on a large-scale MMO for the past 2+ years, from launch through live service. Our server runs on Windows, written in C++20 (MSVC) with an in-house Actor model, protobuf serialization, and our own async framework built on C++20 coroutines. I wanted to share some hard-won lessons that might be useful to others writing performance-critical C++ in production. # 1. A data race in std::sort comparators that led to memory corruption This was our most painful category of bugs. **The root cause was a data race**, but it manifested in a surprising way: a violation of [strict weak ordering](https://en.cppreference.com/w/cpp/named_req/Compare.html) inside `std::sort`, which invokes **undefined behavior** — and in practice, this means **memory corruption**, not a nice crash. **The trap:** We had NPCs sorting nearby targets by distance: std::sort(candidates.begin(), candidates.end(), [&self](const auto& lhs, const auto& rhs) { auto lhs_len = Vec2(self->pos() - lhs->pos()).Length(); auto rhs_len = Vec2(self->pos() - rhs->pos()).Length(); return lhs_len < rhs_len; }); This looks correct at first glance — `<` on floats is a valid strict weak ordering, right? The real problem was that **the objects' positions were being updated by other threads while** `std::sort` **was running.** Each comparator call recomputed distances from live positions, so `compare(a, b)` could return a different result depending on *when* it was called. This breaks transitivity: if `a < b` and `b < c` were evaluated at different moments with different position snapshots, `a < c` is no longer guaranteed. `std::sort` assumes a consistent total order — violate that and it reads out of bounds, corrupting memory. We fixed it by pre-computing distances into a `vector<pair<Fighter*, float>>` *before* sorting, so the comparator operates on stable, snapshot values: for (auto& [fighter, dist] : candidates) { dist = Vec2(self->pos() - fighter->pos()).Length(); } std::sort(candidates.begin(), candidates.end(), [](const auto& lhs, const auto& rhs) { return lhs.second < rhs.second; // comparing cached values — safe }); We found **multiple instances** of this pattern in our codebase, all causing intermittent memory corruption that took weeks to track down. **Lesson:** A comparator that calls any non-const external state is a ticking time bomb. Pre-compute, then sort. # 2. Re-entrancy is a silent killer In an MMO, game logic chains are deeply interconnected. Example: 1. Player uses a skill that heals self on cast 2. HP recovery triggers a debuff check 3. Debuff applies stun, which cancels the skill 4. Skill cancel calls `Stop()` which deletes the current state 5. Control returns to the skill's `BeginExecution()` which accesses the now-deleted state We developed three strategies: |Strategy|When to use| |:-|:-| |**Prevent** (guard with assert on re-entry)|FSMs, state machines — crash immediately if re-entered| |**Defer** (queue for later execution)|When completeness matters more than immediacy| |**Allow** (remove from container before processing)|Hot paths where performance is critical| The "prevent" approach uses a simple RAII guard: class EnterGuard final { explicit EnterGuard(bool* entering) : entering_(entering) { DEBUG_ASSERT(*entering_ == false); // crash on re-entry *entering_ = true; } ~EnterGuard() { *entering_ = false; } bool* entering_; }; This caught a real live-service crash where an effect was being duplicated in a heap due to re-entrant processing during abnormal-status stacking policy evaluation. # 3. Actor model on a 72-core machine: beware the Monolithic Actor Our server uses a **single-process Actor model on 72-core machines** — not a distributed actor system across multiple nodes. The goal is to maximize utilization of all cores within one

Is there a portable version of Visual Studio Runtime? I need to run some portable apps, thanks. And if this isn't the right place to ask, well, divert me to the right place. https://redd.it/1qzyfrx @r_cpp

WCout - a C++ utility to format and display data. It uses '<<' to format, add and display data https://github.com/pinardmichel14-sudo/WCoutSrc https://redd.it/1qzu5g4 @r_cpp

Just figured i know nothing about C++ i claimed to be w C++ programmer bc i know how to code in it but when someone asked me about the the theoretical part of programming/Coding aka C++ i couldn't answer all this months were just pure practice with no real understanding i have a note ready to be filled with pencil writing and idk what to do or where to start or if i should even start from 0 im a game dev and i did some projects in raylib https://redd.it/1qzpdv5 @r_cpp

Como aprender c++? Estoy iniciando 2do semestre de ing de sistemas, este semestre tengo que ver programacion avanzada y la verdad no se como pase introduccion a la programacion, siento que no aprendi nada y todo lo que se viene en avanzada es un salto muy grande comparado con lo anterior, se lo basico pero no he podido avanzar, he visto miles de videos en yotuube, he repasado las clases del semestre anterior y no avanzo, que libros, cursos o que ruta me recomiendan para poder aprender rapido y no perder esta materia que me atrasaria un semestre, por favor ayuda.... https://redd.it/1qzn996 @r_cpp

what motivates you about C++? What motivates you to use and continue learning the language? I mean Ive been messing with C++ for years and its a pretty annoying language to be honest. When I compare it to Python it is awfully complicated. The only reason I still fuk wit C++ is because thats what I learned and I make good buck with it. So yall doing it for the money or the fame? https://redd.it/1qzbtid @r_cpp

Any fun c++ projects i can make in 1-2 weeks I’m not interested in overly complex projects that take months. I’m looking for something fun and unique that, once seen, would make people say, “That’s something new.” I can integrate python or rust based things also in it if required or something related to agentic system Thanks in advance. https://redd.it/1qzca23 @r_cpp

I think build systems shouldn't have variables that affect flags Having cmake, meson etc parse your flags and options is more cumbersome than it worth, and is usually a source of bugs. I think the correct approach for any new toolchain should be to have a separate toolchain file for everything you want to do. A toockhain file should only define binaries and flags. want to have lto? use the toolchain with -flto want to have PIC? use the toolchain that has -fPIC Having cmake take a variable like -DINTERPROCEDURAL_OPTIMIZATION to have a lot build with the same toolchain just leads to bugs. Often some projects simply ignore your flags anyway Also, flags change as compiler version changes. So you have to constantly maintain the build system. \---- I'm honestly tired of projects ignoring my flags, for example llvm compiler RT ignoring add_linkoptions, or cmke ignoring add_compile_options for building std module. I had to use old cxx init variables. I think this was a bad idea from the beginning, A modern build system should just have a nice DSL, and take flags and executables and that's it. It shouldn't deal with other build systems, it shouldn't act as a package manager. It should be a binary, not a python package so the scripting should be built in. Anyway, this was my rant/discussion or whatever. https://redd.it/1qz55an @r_cpp

microsoft/proxy Polymorphism Library is no longer actively maintained under the Microsoft organization After 6 months of announcing new version of this lib, today I found that it's been archived and transferred from Microsoft organization to a new established organization ngcpp two weeks ago. I haven’t been keeping up with the latest cpp news recently, but since the rumor about Microsoft towards C++ last year, I hope this doesn't mean anything bad. https://redd.it/1qz3lhf @r_cpp

"override members" idea as a gateway to UFCS (language evolution) (UFCS backgrounder: https://isocpp.org/files/papers/N4174.pdf ) I have two functions that tell me if a string contains the characters of a particular integer. They're called hasInt and intIn. (intIn is inspired by the python keyword in.) They looks like this: bool hasInt(const string s, int n)// does s have n? { return s.contains(tostring(n)); } bool intIn(int n, const string s)// is n in s? { return s.contains(tostring(n)); } It would be convenient if I could add hasInt as a member function to std::string: bool string::hasInt(int n) { return ::hasInt(this, n); } Then I could use "member syntax" to call the function, like `text.hasInt(123)`. Of course, that's not possible, because then I'd be changing the header files in the standard libraries. Here's an idea for a new language feature: let's use the `override` keyword to allow us to "inject" member functions into an existing class, without modifying the class definition. So the code: override bool string::hasInt(int n) { return ::hasInt(this, n); } will (in effect) add hasInt as a member function to string. Thus, this "override member function" feature has a syntax like: ReturnType ClassName::function(args){...etc...} HOWEVER..... what if ClassName doesn't necessarily need to be a class, and could be other types? Then you open the door to override members like: override bool int::intIn(const string s) { return ::intIn(this, s); } Which allows code like `(123).intIn(text)`. This is halfway to UFCS! Using some macro magic and helper templates, we could define a MAKE_UFCS macro to convert a non-member function into a member function: #define MAKE_UFCS(f) \ override \ retType(f) argType1(f)::f(argType2(f) x)\ { \ return f(this, x); \ } Thus the non-member functions hasInt and intIn could be "opted in" to UFCS by the macro calls: MAKEUFCS(hasInt); MAKEUFCS(intIn); Or maybe, if this override-to-UFCS is useful enough, the override feature can be applied to a collection of functions at once, like: override hasInt, intIn; or override { #include <cstdlib> } To UFCS-ify an entire header file at the same time. EDIT: this idea would be similar to Scala's "Extension Methods": https://docs.scala-lang.org/scala3/book/ca-extension-methods.html or C#'s "Extension Members": https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/extension-methods https://redd.it/1qyikcg @r_cpp

Fintech C++ vs C developer in networking Hey folks 👋 Looking for some grounded, real-world opinions from people who’ve actually worked in these domains. I’m currently an embedded/systems developer working with C, Linux, networking, and Wi-Fi. I’m at a crossroads between two very different domains and trying to figure out which one offers the best learning curve and long-term stability. I currently have three possible tracks: 1) Ofcourse, Broadband / Networking C + Linux + Wi-Fi (6/7), mesh, gateways, ISP stacks — RDK-B, networking protocols, device software. 2) Finance / Wealth Management C++ C++ application development — banking/wealth systems, equity & MF flows. Although i am not sure about the excat work. They require c++ for wealth management software. - As a Broadband Engineer i can work closely with WiFi 7, 6G, and Mesh technologies. - And I'm not so aware about the opening for C++ Devs in this area. My main question: 1) Over a 10–15 year horizon, which path offers: Better learning depth, Career stability, Flexibility to move roles or domains. If you had to pick one domain for 2026 and beyond, which would it be and why? Not looking for a “this pays more” answer. More interested in signal vs noise, saturation vs skill, and long-term optionality. Would love to hear from people actually working in these areas 🙏 https://redd.it/1qymtpz @r_cpp

WCout - a C++ utility that simplifies data formatting and display. It uses only '<<' to format, add and display data https://github.com/pinardmichel14-sudo/WCoutSrc https://redd.it/1qy4jf1 @r_cpp