C++ - Reddit

SFML 3.1 is released https://github.com/SFML/SFML/releases/tag/3.1.0 https://redd.it/1sndilj @r_cpp

GUI toolkit Slint 1.16 released with keyboard shortcuts, Markdown rendering, and multi-touch pinch and rotate https://slint.dev/blog/slint-1.16-released https://redd.it/1snc6ow @r_cpp

Achieving 56.5 ns cross-language IPC latency: Defeating false sharing and bypassing the kernel. Hi, I recently open-sourced Tachyon, a low-latency shared-memory IPC library I’ve been working on. The goal was to reach RAM-speed communication between processes (C++, Rust, Python, etc.) without any serialization overhead or kernel involvement on the hot path. I managed to hit a p50 round-trip time of 56.5 ns (for 32-byte payloads) and a throughput of \~13M RTT/sec on an i7-12650H, which is about 150x faster than ZeroMQ inproc. Here are a few architectural choices I made to achieve this, which I thought might interest this sub: Strict SPSC & No CAS: I went with a strict Single-Producer Single-Consumer topology. There are no compare-and-swap loops on the hot path. acquire_tx and acquire_rx are just a load, a mask, and a branch using memory_order_acquire/release. Hardware Sympathy: Every control structure (message headers, atomic indices) is padded to 64-byte or 128-byte boundaries. False sharing between the producer and consumer cache lines is structurally impossible. Hybrid Wait Strategy: The consumer spins for a bounded threshold (cpu_relax()), then sleeps via SYS_futex (Linux) or __ulock_wait (macOS). Zero-Copy: The hot path is entirely in the memfd shared memory segment after an initial Unix Domain Socket handshake. The core is C++23 (compiled with GCC 14+/Clang 17+), and it currently has bindings for 6 other languages. Repository: https://github.com/riyaneel/Tachyon I’d love to get some feedback from the C++ community on the architecture, especially regarding the memory model implementation and the hybrid futex spin-wait strategy. Thanks! https://redd.it/1sn8a1y @r_cpp

Special meetup with Bjarne Stroustrup in Florence Hi everyone! I am organizing a special meetup with Bjarne Stroustrup in Florence on Saturday, May 9! Schedule: 09:30 – Doors open 10:00 – Welcome message 10:15 – Technical session: “Concept-based Generic Programming” 11:45 – Short break 12:00 – Live AMA with Bjarne Stroustrup 13:00 – Closing The event will take place at the University of Florence (Novoli Campus) and is organized by the Italian C++ Community, the University of Florence, and the University of Pisa. For developers traveling from abroad, this is also a great excuse to visit Florence, while connecting with the Italian C++ community. Free registration and details: https://italiancpp-fi26.eventbrite.it/ Looking forward to seeing you there! https://redd.it/1sn2g4d @r_cpp

C++23 std::stacktrace: Never Debug Blind Again https://medium.com/@sagar.necindia/c-23-std-stacktrace-never-debug-blind-again-6625924d520c https://redd.it/1sn2nnb @r_cpp

Annotations for C++26 Hashing https://blog.infotraining.pl/annotations-for-cpp-26-hashing https://redd.it/1smz1rm @r_cpp

boost::container::hub review starts today (April 16 - April 26) Announced officially [in the Boost developer mailing list](https://lists.boost.org/archives/list/boost@lists.boost.org/thread/6ER3ZA4VMVKB57DDEXKO26UVYBP7I3QP/): **Introduction** The formal review of Joaquín M López Muñoz's boost::container::hub container, for inclusion in the Boost.Container library, starts today. "hub" is a sequence container with O(1) insertion and erasure and element stability [with great performance (see these benchmarks)](https://github.com/joaquintides/hub/blob/develop/README.md#performance): pointers/iterators to an element remain valid as long as the element is not erased. hub is very similar but not entirely equivalent to C++26 std::hive (hence the different naming, [consult the section "Comparison with std::hive" for details)](https://github.com/joaquintides/hub/blob/develop/README.md#comparison-with-stdhive). It may be downloaded from: [https://github.com/joaquintides/hub](https://github.com/joaquintides/hub) the documentation may be found here: [https://github.com/joaquintides/hub/blob/develop/README.md](https://github.com/joaquintides/hub/blob/develop/README.md) Anyone is welcome to post a review and/or take part in subsequent discussions in the mailing list. **Review guidelines** Please provide feedback on the following general topics: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? Do you already use it in industry? * Did you try to use the library? With which compiler(s)? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? Ensure to explicitly include with your review: ACCEPT, REJECT, or CONDITIONAL ACCEPT (with acceptance conditions). Ion Gaztañaga (Review Manager) https://redd.it/1smx361 @r_cpp

C++26: Structured bindings in conditions https://www.sandordargo.com/blog/2026/04/15/cpp26-structured-bindings-condition https://redd.it/1smrf3p @r_cpp

option, as per https://aka.ms/msvc/preview To install an older in-support release, you need to run the Visual Studio installer, switch to the 'Individual Components' tab, and find the 14.5* toolset to install. If you are on the Insiders channel, only had the default MSVC toolset chosen, and recently upgraded, you'll see that your 14.50 toolset was replaced with 14.51... add it back in the 'Individual Components' tab. # Why are we doing this? The biggest benefit of the new model is to vastly shorten the distance between MSVC features and folks using them in a Preview. Folks on the MSVC development team can make a change which ships in the next week or so. This timeframe used to be months, but has now shortened to just a week. Not all C++ users want this, so MSVC Previews are an optional installation component. Most of the other reasons are called out in https://aka.ms/msvc/lifecycle: The MSVC team is leaning into the Visual Studio release cadence We are aligning our long-term-servicing releases with those of .NET Servicing 10+ year old compilers has become increasingly complex. # tl;dr, and what should folks do? If you want the bleeding edge tools, stay on the Visual Studio Insiders channel and install the 'MSVC Build Tools for <arch> (Preview)' option. Please give us feedback by reporting bugs on https://developercommunity.visualstudio.com/ or through the Visual Studio IDE itself. If you want stable tools that only update every 6 months, stick with the Visual Studio Stable channel, and use the default C++ tools. Want to get a head start on the every-6-months update? Look for our release candidate blog posts (https://devblogs.microsoft.com/cppblog/msvc-build-tools-version-14-51-release-candidate-now-available/), and use Visual Studio Insiders with the default C++ options. Thanks for reading. https://redd.it/1smfgdu @r_cpp

Demystifying MSVC versioning for 14.50 & later Hi folks, one of the MSVC dev leads here. MSVC versioning is confusing, and with the change to decouple MSVC releases from Visual Studio releases (https://aka.ms/msvc/lifecycle) it's confusing-er. This post aims to clarify what's going on with 14.50 & later. I am intentionally skipping discussion of the VS2022 & older releases that are still being supported since the servicing model is different. Know that our team still supports Visual Studio 2019 16.11 per https://learn.microsoft.com/en-us/visualstudio/releases/2019/servicing-vs2019, and Visual Studio 2022 17.12 & 17.14 as per https://learn.microsoft.com/en-us/visualstudio/releases/2022/servicing-vs2022 . # The actual versions Since MSVC releases are decoupled from Visual Studio releases, it's helpful to think from the standpoint of the MSVC toolchain. At any point in time, we ship: The bleeding edge preview toolset The current default toolset All previous in-support toolsets As of today, we ship the following MSVC toolsets: 14.52 the preview toolset, built from our development branch last Tuesday (April 7th) `14.51` the default toolset, currently a 'release candidate' 14.50 the toolset we released in Nov 2025, with 3 years of support. Our plan, as per https://aka.ms/msvc/lifecycle, is to ship a new 14.5* twice a year. So in 6 months we expect to ship 14.53 as the new 'latest preview', make 14.52 the 'current default toolset', and 14.51 will be a toolchain in support as per the support policy, along with 14.50. # What's this about Visual Studio Insiders vs. Stable? Visual Studio 'stable' ships monthly (https://learn.microsoft.com/en-us/visualstudio/releases/2026/release-rhythm), so if you're on the Visual Studio stable channel you'll get monthly updates to all the 14.5* toolsets. To be explicit: The latest preview will be updated with whatever the dev team has landed in the last month The default & other in-support toolsets will be updated with the latest fixes we have applied to them. If you want to get MSVC toolset updates far quicker than monthly, switch to the Visual Studio Insiders channel https://visualstudio.microsoft.com/insiders/. Keep an eye on https://learn.microsoft.com/en-us/visualstudio/releases/2026/release-notes-insiders for how often these updates occur. Want just the far-quicker-than-monthly MSVC build tools and not the full Visual Studio? Use the build tools sku: http://aka.ms/vs/insiders/vs\_buildtools.exe  # Wait, you said something about a 'release candidate'? We blogged recently https://devblogs.microsoft.com/cppblog/msvc-build-tools-version-14-51-release-candidate-now-available/ that the default toolset is moving from 14.50 to 14.51. As per https://aka.ms/msvc/lifecycle we aim to ship a new default toolset every 6 months. However, about a month before this lands in the Visual Studio 'Stable' channel we want to land the new default toolset in the 'Insiders' channel. This gives folks using Insiders about a month to give us feedback to fix 14.51 bugs before it shows up for 'Stable' channel users. # How do I get these tools? Why did 14.50 disappear yesterday? Where is 14.52? When you install Visual Studio (using any channel) and select the Desktop development with C++ workload, you only get the default MSVC toolset. To install the 'latest preview' you need to run the Visual Studio installer and select the MSVC Build Tools for <arch> (Preview)

Announcement: cppreference.com update https://isocpp.org/blog/2026/04/announcement-cppreference.com-update https://redd.it/1smb1co @r_cpp

How std::abs and two compiler flags let Clang auto-vectorize L1 distance faster than Faiss's AVX2 intrinsics https://blog.serenedb.com/simd-distances https://redd.it/1sm4clo @r_cpp

I'm building an open-source OS that can run Windows, Linux, and macOS apps together (looking for contributors) Hey everyone, I’ve been working on an idea that I think a lot of us have been frustrated by at some point: Why is software still locked into operating system silos? Windows apps only run on Windows Linux tools require Linux environments macOS software is completely isolated So I started building a project (working title: FusionOS) that aims to change that. # The idea A universal execution layer + OS where: Windows, Linux, and macOS applications can run side-by-side Environments are abstracted away from the user Compatibility is handled at the system level On top of that, I’m exploring a multi-agent architecture where: Agents manage dependencies and environments Tasks can be automated and optimized dynamically # Current direction Right now I’m in the early stage, exploring: Binary translation / compatibility layers Virtualization + container hybrids Cross-platform system abstractions Agent-based orchestration # Why I’m posting here This is obviously a hard systems problem, and I don’t want to build it alone. I’m looking for people interested in: OS dev / kernels low-level systems (C/C++/Rust) virtualization / compilers or even just thinking about better abstractions Even if you just want to discuss the idea or poke holes in it, that’s super valuable. # Repo https://github.com/Martin-Aziz/FusionOS https://redd.it/1sm2u48 @r_cpp

C++ Profiles: What, Why, and How at using std::cpp 2026 https://www.youtube.com/watch?v=Z6Nkb1sCogI https://redd.it/1sm1u3b @r_cpp

C++ Committee Q&A at using std::cpp 2026 https://www.youtube.com/watch?v=iD5Bj7UyAQI https://redd.it/1slyw6q @r_cpp

How a Module Should Look Like https://abuehl.github.io/2026/04/14/how-a-module-should-look-like.html https://redd.it/1slxp2o @r_cpp

MS Visual Studio 18.5 has now been Released, with one caveat... ...It still doesn't have MSVC Build Tools v14.51, only an old preview. https://learn.microsoft.com/en-us/visualstudio/releases/2026/release-notes At the same time, Microsoft releases Visual Studio Insiders (basically VS preview), with the MSVC Build Tools v14.51 release, not a preview. https://learn.microsoft.com/en-us/visualstudio/releases/2026/release-notes-insiders So, now we have - official VS Release with the MSVC Build Tools v14.51 preview. And VS preview with the MSVC Build Tools v14.51 release. Person (or persons?...) in Microsoft responsible for this weirdness should get annual bonus reward. https://redd.it/1slomwh @r_cpp

NDC Techtown conference in Norway (Kongsberg) The deadline for submitting talks to NDC Techtown 2026 is still open. This great SW development conference takes place in Kongsberg, Norway on 21st to 24th September and focuses on SW development for embedded and systems programming. The conference covers travel and accommodation. More info here: https://ndctechtown.com/call-for-papers https://redd.it/1slfkh6 @r_cpp

A year of read-only cppreference Over a year ago (on 30 March 2025), cppreference became read-only for maintenance reasons. Since then, the only progress update was in August. There have been several discussions here in the last few months about what is happening with cppreference and when it might become editable again, but from what I understand, we simply do not know. At this point, I fear that the lack of updates for what is basically the authoritative source on the language (other than the standard of course), linked to by IDEs and even this subreddit's sidebar, might be detrimental to the adoption of C++26 and further standards, should the situation persist. I would therefore like to ask the community whether there are other, more up-to-date resources, and whether there is any effort to, for example, fork cppreference. I understand that software updates are complicated and I have no intention to criticise the maintainers of cppreference (who are doing it voluntarily and I am not entitled in any way to their continued work on the website), but I do not think the C++ community can afford to be bottlenecked in such a way for much longer. https://redd.it/1slfh4p @r_cpp

How Much Linear Memory Access Is Enough? (A Benchmark) https://solidean.com/blog/2026/how-much-linear-memory-access-is-enough/ https://redd.it/1slaltv @r_cpp