Welcome to SwedenCpp

Latest blogs, videos, podcasts and releases in one stream

Wednesday, April 15, 2026

This page runs on coffee, please consider supporting it.

Tuesday, April 14, 2026

Monday, April 13, 2026

Sunday, April 12, 2026

Saturday, April 11, 2026

Preventing Integer Overflow in Physical ComputationsPreventing Integer Overflow in Physical Computations Integers overflow. That is not a controversial statement. What is surprising is how easily overflow can hide behind the abstraction of a units library. Most developers immediately think of explicit or implicit scaling operations — calling .in(unit) to convert a quantity, constructing a quantity from a different unit, or assigning between quantities with different units. These are indeed places where overflow can occur, and the library cannot prevent it at compile time when the values are only known at runtime. But at least these operations are visible in your code : you wrote the conversion, you asked for the scaling, and you can reason about whether the multiplication or division might overflow your integer type. The far more insidious problem is what happens when you don't ask for a conversion. When you write 1 * m + 1 * ft , the library must automatically convert both operands to a common unit before performing the addition. That conversion — which you never explicitly requested — involves multiplication or division by scaling factors. With integer representations, those scaling operations can overflow silently, producing garbage results that propagate through your calculations undetected. No compile-time programming can prevent this. The values are only known at runtime. But very few libraries provide proper tools to detect it. This article explains why that limitation is real, how other libraries have tried to work around it, and what mp-units provides to close the gap as tightly as the language allows.📝mp-units

Friday, April 10, 2026

Building C/C++ libraries for HarmonyOS with vcpkgWe're currently working on porting Qt to HarmonyOS . For our CI and developer machines, we need a number of third-party libraries built for HarmonyOS. Cross-compiling open-source C and C++ libraries for this platform has been a manual, error-prone process. Each library has its own build system, whether CMake, Autotools, or Meson. Each needs individual attention to produce correct binaries for the OHOS target. We have been maintaining a hand-written shell script that builds libraries one by one, with per-library workarounds for cross-compilation quirks. With our vcpkg fork, that script is now a single command.📝Qt Blog

Thursday, April 9, 2026

A brief history of C/C++ programming languagesInitially, we had languages like Fortran (1957), Pascal (1970), and C (1972). Fortran was designed for number crunching and scientific computing. Pascal was restrictive with respect to low-level access (it was deliberately “safe”, as meant for teaching structured programming). So C won out as a language that allowed low-level/unsafe programming (pointer arithmetic, direct memory access) … Continue reading A brief history of C/C++ programming languages📝Daniel Lemire's blog

Wednesday, April 8, 2026

Bazel Q1 2026 Community UpdateAnnouncements Mark Your Calendars: BazelCon 2026 is Heading to Amsterdam! Get ready to build at scale in the heart of Europe. We are thrilled to announce that BazelCon 2026 will be taking place in the vibrant city of Amsterdam from October 13th–15th . Whether you’re a seasoned build engineer or just starting your journey with monorepos and hermeticity, this is the place to be. Expect three days of deep-dive technical sessions, hands-on workshops, and the chance to connect with the global community of maintainers and power users. The Details at a Glance: What: BazelCon 2026 Where: Postillion Hotel & Convention Centre Amsterdam, Netherlands When: October 13–15, 2026 October 13th - Training Day October 14th & 15th - 2 Conference days filled with technical sessions, Birds of a Feather and networking with the best in the field. Registration opens April 22nd - register via the BazelCon website ! For the most up to date BazelCon news and updates, follow the Bazel X account and the #bazelcon Bazel Slack channel. Call for Proposals Do you have a Bazel story to tell? We want to hear how you're using Bazel to solve complex problems, whether you’re optimizing massive monorepos or building custom rules for your team. Sharing your real-world wins and lessons learned helps the entire community grow, so don't hesitate to submit a proposal regardless of your experience level. CFP Opens: April 22 CFP Closes: June 21 Review Period: June 22 – July 8 Speaker Notifications: July 20 Schedule Announcement: July 22 The CfP submission form will be available via the BazelCon website . Want to become a Sponsor of BazelCon 2026? Hosted by the Bazel Community in partnership with The Linux Foundation, BazelCon is the premier annual event for build enthusiasts, maintainers, and contributors to connect in an inclusive environment. Sponsoring BazelCon 2026 puts your company right in front of the best build and platform engineers in the business. It is a great way to show your support for the community, meet key decision-makers, and find top talent to join your team. By becoming a partner, you help make the event possible while making sure the smartest people in tech know exactly who you are. Download the 2026 Sponsorship Prospectus Here. Email us at bazelcon-planning@bazel.build to reserve your sponsorship, ask questions, or talk about different options. Product Updates Upcoming Bazel releases Bazel 9.1.0 is expected to release on on 2026-04-16. Please send cherry-pick PRs against the release-9.1.0 branch before the RC1 cutoff on 2026-04-09. Bazel 8.7.0 is expected to release on 2026-05-04. Please send cherry-pick PRs against the release-8.7.0 branch before the RC1 cutoff on 2026-04-27. Q4 & Q1 releases 9.0.0 has been released in January ‘26, followed by patch 9.0.1 . 8.6.0 has been released in February ‘26. 8.5.0 has been released in December ‘25, followed by patch 8.5.1 . 7.7.0 has been released in October ‘25, followed by patch 7.7.1 . 6.6.0 has been released in January ‘26. This release has also marked the end of support for Bazel 6. Community Corner Bazel for CLion plugin updates A few updates from the JetBrains* team: Plugin supports Bazel 9 and comes now with Starlark REPL. C++ code insight under transitions is being rolled out. CLion Classic lets the user select resolve configuration for such files if more than one configuration is available, CLion Nova support for configuration switching is on the way. GoogleTest TEST_P macro is supported for individual test runs. Code insight takes into account conlyopts and cxxopts attributes. New PTY capable view is enabled by default for all outputs. BUILD Foundation Announced at BazelCon 2025, the BUILD Foundation has been established as a Linux Foundation Directed Fund to accelerate the community roadmap for Bazel and related build technologies. While Google maintains governance of the core Bazel "kernel," the new fiscal entity provides a formal structure to fund improved documentation, rulesets, and open-source infrastructure. The BUILD Foundation is now enrolling founding members. Read the Prospectus and Membership Entitlements to learn more about the values of becoming a member. Web Updates: Previews for the BCR and Bazel.build A New Look for the BCR: The community is working together on a more modern way to explore the Registry. Head over to bcr.stack.build to see the new UI in action and see how the ecosystem is evolving. Evolving Bazel.build: Thanks to a collaborative effort, the next version of our homepage is taking shape. Visit preview.bazel.build to see how we’re making documentation and resources easier for everyone to navigate. Upcoming Meetup.build events Build Meetup Munich - May 11, 2026 Community created content Articles Goodbye Dockerfile, Hello Bazel: Doubling Our CI Speed - by Nikita Chepanov and Oleg Dashevskii at Plaid Build less, merge faster: avoiding diamond merges with a merge queue - by Nikita Chepanov and Oleg Dashevskii at Plaid Bazel 9 Migration: How to Get Faster Builds Before the Bzlmod Refactor - by Pratik Mahalle Bazel for SONiC: What We've Learned and Contributed - by Şahin Yort Managing Bazel Flags in Monorepos with Flagsets (PROJECT.scl) - by Adin Ćebić Composing Bazel rules with subrules - by Adin Ćebić Lightning-fast BUILD file generation with Gazelle lazy indexing - by Jay Conrod @EngFlow Bazel rule extensions - by Keith Smiley Build Snippets #1 - Affected Target Analysis with Bazel - by Chris McDonald Migrating to Bazel symbolic macros - by Alexey Tereshenkov @Tweag Videos Bazel 9 is here! - by Aspect Build Tutorial: Set up Gazelle to automatically create your Bazel BUILD files - & other beginner friendly videos by Jon Block here . Bazel and Rust at OpenAI with David Zbarsky - by Aspect Build Zero-sysroot hermetic LLVM cross-compilation using Bazel - FOSDEM talk by David Zbarsky and Corentin Kerisit Resources GitHub repository: https://github.com/bazelbuild/bazel Releases: https://github.com/bazelbuild/bazel/releases Slack chat: https://slack.bazel.build Google group: bazel-discuss@googlegroups.com Special Interest Groups (SIG): Reach out the email(s) listed below if you’d like to be added to the SIG calendar invites. SIG Meeting frequency Point of contact Rules authors Every two weeks bazel-contrib@googlegroups.com Android app development Monthly ahumesky@google.com Bazel plugin for IntelliJ Monthly en@jetbrains.com Remote execution API working group Monthly chiwang@google.com Supply chain security / SBOM Weekly fwe@google.com Interested in learning about SIGs or starting a new one? Find more information on our website . Want to get your SIG listed? Please add it to the Community repository . Ideas, feedback, and submissions are welcome! Thank you for reading this edition! Let us know if you’d like to see any new information or changes in future community updates by reaching out to product@bazel.build. We look forward to hearing from you. Thanks, Google Bazel team * Copyright © 2026 JetBrains s.r.o. JetBrains and IntelliJ are registered trademarks of JetBrains s.r.o.📝Bazel Blog
Joining Community, Detecting Communities, Making Community.Joining Community Early in Q1 2026, I joined the C++ Alliance. A very exciting moment. So I began to work early January under Joaquin’s mentorship, with the idea of having a clear contribution to Boost Graph by the end of Q1. After a few days of auditing the current state of the library versus the literature, it became clear that community detection methods (aka graph clustering algorithms) were sorely lacking for Boost.Graph, and that implementing one would be a great start to revitalizing the library and fill up maybe the largest methodological gap in its current algorithmic coverage. Detecting Communities The vision was (and still is) simple: i) begin to implement Louvain algorithm, ii) build upon it to extend to the more complex Leiden algorithm, iii) finally get started with the Stochastic Block Model. If the plan is straightforward, the Louvain literature is not, and the BGL abstractions even less. But under the review and guidance from Joaquin and Jeremy Murphy (maintainer of the BGL), I was able to put up a satisfying implementation: Using the Newman-Girvan Modularity as the quality function to optimize, one can simply call: double Q = boost::louvain_clustering( g, cluster_map, weight_map, gen, boost::newman_and_girvan{}, // quality function (default) 1e-7, // min_improvement_inner (per-pass convergence) 0.0 // min_improvement_outer (cross-level convergence) ); // Q = 0.42, cluster_map = {0,0,0, 1,1,1} As it happens often with heuristics, there is a large number of quality functions out there, and this is not because of a lack of consensus: in a 2002 paper, computer scientist Jon Kleinberg proved that no clustering quality function (Modularity, Goldberg density, Surprise…) can simultaneously be: scale-invariant (doubling all edges should not change the clusters), rich (all partitions should be achievable), consistent (shortening distances inside a cluster and expanding distances between clusters should lead to similar results). In other words, there is no way to implement a single function hoping it would exhibit three basic properties we would genuinely expect. All we can do is to explore different trade-offs using different quality functions. So I left some doors open to be able to inject an arbitrary quality function. If this function exposes a minimal, “naive” interface, the algorithm will statically use a slow but generic path, and iterate across all the edges of the graph to compute the quality. It is slow, yes, but it makes the study of qualities easier, as one does not have to figure out the local mathematical decomposition of the function to get started with coding: struct my_quality { template typename boost::property_traits ::value_type quality(const G& g, const CMap& c, const WMap& w) { // your custom partition quality function } }; double Q = boost::louvain_clustering(g, cluster_map, weight_map, gen, my_quality{}); However, the Louvain algorithm is extremely popular because it is fast, as it is able to update the quality computational state for each vertex it tries to “insert” or “remove” from a neighboring putative community. This locality decomposition has to be figured out mathematically for each quality function, so it’s not trivial. I defined a GraphPartitionQualityFunctionIncrementalConcept that refines the GraphPartitionQualityFunctionConcept : if the algorithm detects that the injected quality function exposes an interface for this incremental update, the fast path is taken. One thing I figured out is that the GraphPartitionQualityFunctionIncrementalConcept is for now too specific to the Modularity family. I am currently working on a proposal to increase its scope in future work. The current PR has been carefully tested and benchmarked for correctness and performance, and validated by Jeremy to be merged on develop branch. I wrote a paper to be submitted to the Journal of Open Source Software to publish the current results and benchmarks, as we are at least as fast as our competitors, and more generic. There is no equivalent I am aware of. Making Community Concurrently, I worked on summoning the Boost.Graph user base, and it quickly became clear a small local workshop would be a tremendous start: the Louvain algorithm community is based in Louvain (Belgium), its extension was formulated in Leiden (Netherlands) and my PhD graphs network is based in Paris (France) in what has been presented to me as “the Temple of the Stochastic Block Model” ! Quite a sign: life finds ways to run in (tight) circles. So the goal of this workshop is to bring together a small group (10-15 people) of researchers, open-source implementers, and industrial users for a day of honest conversation on May 6th 2026. Three questions will anchor the discussions: What types of graphs and data structures do you use in practice? What performance, scalability, and interpretability requirements matter most to you? What algorithms are missing today that Boost.Graph could offer? Ray and Collier from the C++ Alliance will also be there to record the lightning talks and document the process. It would also be the occasion to show off the python-based animations I put together for the French C++ User Group presentation on March 24th. Those had a nice success and received many compliments, as it pairs well with the visual and dynamic nature of graphs and their algorithms, and I hope it will contribute to the repopularization of Boost.Graph. Graphliiings asseeeeemble !📝The C++ Alliance