Welcome to SwedenCpp

Latest blogs, videos, podcasts and releases in one stream

Wednesday, July 15, 2026

If this page is useful, please consider donating a coffee

Tuesday, July 14, 2026

Rethinking C++ Performance: Faster Code Navigation and GitHub Copilot Tools with Whole Codebase IndexingIn large C++ codebases, your code understanding and navigation depend on quickly determining how symbols, declarations, definitions, and references are connected across your project. In Visual Studio Insiders 18.9, the new whole codebase indexing (WCI) enhances the existing browse database via a deeper, more comprehensive indexing approach. This preview feature allows Visual Studio to access [โ€ฆ] The post Rethinking C++ Performance: Faster Code Navigation and GitHub Copilot Tools with Whole Codebase Indexing appeared first on C++ Team Blog .๐Ÿ“C++ Team Blog
The Prompt-Wait-Evaluate Loop: How AI Kills Flow Without You NoticingA few months ago, I wrote about finding joy in programming in the age of AI. In the personal discussions Iโ€™ve had with fellow developers โ€” both before and after that article โ€” one thing keeps striking me. Most people donโ€™t argue. They just say: yes, thatโ€™s exactly how it feels. But a question kept coming up in those conversations: why does it feel this way? Not in the philosophical sense โ€” I c...๐Ÿ“Sandor Dargo's Blog

Monday, July 13, 2026

Pure Virtual C++ 2026 [Meet the Speakers, Part 2]: The AI-Native C++ Developer WorkflowPure Virtual C++ 2026 streams Tuesday, July 21, 2026 at 9:00 AM PT, a free, one-day virtual conference for the whole C++ community, live on YouTube (Microsoft Reactor) and Twitch, with on-demand recordings on the Visual Studio YouTube channel afterward. Register now โ†’ Welcome to part two of our Meet the Speakers series. In part one we looked at building and running [โ€ฆ] The post Pure Virtual C++ 2026 [Meet the Speakers, Part 2]: The AI-Native C++ Developer Workflow appeared first on C++ Team Blog .๐Ÿ“C++ Team Blog

Sunday, July 12, 2026

Irreducible loopsThe dominator tree lets us identify natural loops : a back edge T->H whose head H dominates its tail T defines a loop with the single entry H . This works only for reducible control flow graphs. Optimized machine code and decompiler output routinely contain irreducible loops, which have more than one entry and thus no dominating header, so the dominator-based method cannot see them. This post builds a loop-nesting forest for an arbitrary CFG with the single-pass depth-first search of ้Ÿฆ้Ÿฌใ€ๆฏ›ๅ‰‘ใ€้‚น็ปดใ€้™ˆๅฎ‡(Tao Wei, Jian Mao, Wei Zou & Yu Chen) A New Algorithm for Identifying Loops in Decompilation , SAS 2007 (The 14th International Static Analysis Symposium).๐Ÿ“MaskRay

Saturday, July 11, 2026

X just gave us an interface that AI agents can use. I pointed it at my own posts.I have been on X for a long time. Like most people who post regularly, I have a gut feeling for what might interest people. I post in the morning. Longer posts seem to do better. But gut feelings are not measurements. And until recently, digging into your own posting data meant either clicking around โ€ฆ Continue reading X just gave us an interface that AI agents can use. I pointed it at my own posts.๐Ÿ“Daniel Lemire's blog

Friday, July 10, 2026

Whatโ€™s in a Warning?For a while, users have been asking for CMake to do a better job of warning about undesirable uses, such as using functions that should not be used in โ€œmodernโ€ CMake. Starting with CMake 4.4, we are finally making inroads on those requests, but the journey there went through some interesting and unexpected territory. This is a bit of a peek โ€œunder the hoodโ€ of CMake development, which is a bit of a deviation for a normally user-focused blog, but we wanted to share because it has the potential to impact users, and we wanted to explain why we felt the changes, and the potential pain associated with them, are warranted.๐Ÿ“Kitware Inc
Using some modern C++ features to avoid macrosRecently I had an opportunity to use some non-obvious C++ language features, which in those days doesn't happen that often to me. ๐Ÿ˜ž To be frank, lately I'm doing more QML and JavaScript programming than pure C++, so I was more than happy to be able to jump into the challenge. The (arguably small) problem I had, was that I had to define a seemingly endless amount of callback functions all doing basically just the same thing: auto callb = [this](std::expected result) -> void { if (result.has_value()) { emit okNotification(result.value()); logCallback("BlaBlaCallback " + std::to_string(result.value())); } else { emit errorNotification(std::to_underlying(result.error())); logCallback("BlaBlaCallback ERROR: " + std::to_string(std::to_underlying(result.error()))); } }; As you can see, I was working with Qt and I used their signal/slot mechanism. In this context the emit clause sends a signal to all parties that subscribed for it. So basically we need a callback that looks into a std::expected value and decides what kind of a Qt signal has to be sent - an error notification or a value change one. Additionally, std::expected result can contain values of different types: integers of different ranges and signs, as well as floating point numbers and enum values. 1. The definition The first idea to come (because I'm oldskool?) was a macro . I even wrote one, but then I said to myself - come on, that's ugly, Bjarne working all the time to give us mechanism to make macros obsolete and now I write that abomination? So, ashamed, I deleted it immediately and started with a template-based solution. As templates are kinda oldskool themselves, I wanted to try polymorphic lambdas first , hoping that maybe compiler can figure out all that parametrization stuff for me and I will just write down the auto keyword and everything will be good in the world. So I wrote this piece of code: auto makeUint32Callback = [this](auto notifOk, auto notifErr, const std::string& label) { return [this, notifOk, notifErr, label](std::expected result) -> void { if (result.has_value()) { emit (this->*notifOk)(result.value()); logCallbacks(label + " " + std::to_string(result.value())); } else { emit (this->*notifErr)(std::to_underlying(result.error())); logCallbacks(label + " ERROR: " + std::to_string(std::to_underlying(result.error()))); } }; }; As you can see, I defined a helper function (a lambda in the local scope), which constructs the final lambda from provided parameters, which final lambda can then serve all callbacks reporting value changes for values of type uint32 ! Nice one, but what about other value types? Do we have to define makeInt32Callback(), makeUint8Callback(), makeFloatCallback() etc? We certainly don't want that! To the rescue comes a C++20 feature called templated lambdas . Don't fear, it's very simple, we just give a type parameter to the lambda and it's all we need here: auto makeTypedCallback = [this] (auto notifOk, auto notifErr, const std::string& label) { return [this, notifOk, notifErr, label](std::expected result) -> void { if (result.has_value()) { emit (this->*notifOk)(result.value()); logCallbacks(label + " " + std::to_string(result.value())); } else { emit (this->*notifErr)(std::to_underlying(result.error())); logCallbacks(label + " ERROR: " + std::to_string(std::to_underlying(result.error()))); } }; }; As easy as that! We then just forward the type parameter T to the std::expected parameter definition and that's it. Now we even can go further and add support for enum types using an if constexpr construct inside of the lambda: auto makeMyCallback = [this] (auto notifOk, auto notifErr, const std::string& label) { return [this, notifOk, notifErr, label](std::expected result) -> void if (result.has_value()) { if constexpr (std::is_enum_v ) { emit (this->*notifOk)(std::to_underlying(result.value())); logCallbacks(label + " " + std::to_string(std::to_underlying(result.value()))); } else { emit (this->*notifOk)(result.value()); logCallbacks(label + " " + std::to_string(result.value())); } } else { emit (this->*notifErr)(std::to_underlying(result.error())); logCallbacks(label + " ERROR: " + std::to_string(std::to_underlying(result.error()))); } }; }; When seeing if constexpr compiler will decide which branch of the code has to be taken and which has to be ignored. And all that at compile time! 2. The invocation Now as we have our templated, polymorphic lambda ready, we just invoke it for each pair of notifications and we are done! But how exactly should we invoke a templated lambda? Somehow it's not that obvious. We could try to do it the standard way, just as we always have done with data structurers, i.e. like that: auto callb = makeMyCallback ( &NotifThreadWrapper::operationModeChanged, &NotifThreadWrapper::operationModeChangeError, "OperationModeCallback"); But the compiler won't let us have it! ๐Ÿ˜ž The right way, however, is: auto callb = makeMyCallback.operator() ( &NotifThreadWrapper::operationModeChanged, &NotifThreadWrapper::operationModeChangeError, "OperationModeCallback"); Why's that? Well, as it turns out, you cannot templatize a lambda as a whole, but you can only templatize its function call operator! An that is what the funny looking syntax does: lambda.operator() (args) , the type T comes after the call operator. If you think about it, it is quite logical, a lambda is just a generalized function, so you parametrize the function call, right? Because, c ome on, it's even declared like that: [] (T x) { /* ... */ } in the first place! On the other hand however it is just syntax, and the Standard Committee could add support for the first invocation as well. The chose not to. 3. Extending it further Some time later I added some new callbacks taking a std::pair of something as parameter. How can we support this new callback type in the makeMyCallback() helper? Simple, another if constexpr will do it: ... else if constexpr (is_pair_v ) // why not std::is_pair_v ??? { emit (this->*notifOk)(result.value().first, result.value().second); logCallbacks(label + " " + std::to_string(result.value().first) + "/" + std::to_string(result.value().second)); } However, because apparently there isn't a std::is_pair_v predicat e in the standard library ๐Ÿ˜ฎ, I also had to provide following definitions: template struct is_pair : std::false_type {}; template struct is_pair > : std::true_type {}; template inline constexpr bool is_pair_v = is_pair ::value; Easy, but std::is_pair would be so much nicer! 4. Wrap-up And there it is: a polymorphic, templated lambda returning a lambda , thus clearly being a metafunction* (yay!). Or can we call it meta-lambda/metalambda? Now you know how to write yourself one and, what's maybe even more important, also how to invoke it and put it to good use instead of polluting your code with ugly macros! __ * metafunctions - function returning other functions, it should be pretty clear? But it isn't. For example Boost MPL libraray ( "...high-level C++ template metaprogramming framework of compile-time algorithms, sequences and metafunctions." ) defines them quite differently: "... A metafunction is a class or a class template that represents a function invocable at compile-time", thus clearly meaning just a * constexpr * function. Hmmm... ๐Ÿค” Other definition I've seen are "...functions that operate on types, rather than traditional runtime values" or "...Metafunctions are program elements (classes in C++) that can return computed types" . This definition makes more sense than the MPL one, but how can we then name a lambda returning a lambda? Here I chose to stick to functional programming nomenclature where I first learned that concept: "...A metafunction is simply a function that operates on other functions or on representations of functions, often at the metaโ€‘level (i.e., reasoning about code, types, or syntax rather than just data)". Of course, we could also use the (more correct) term "higher order functions" , but "metafunction" sounds so much crispier ๐Ÿ™‚, so I hope you will forgive me this little stretch of nomenclature.๐Ÿ“On Software and Languages
Democratizing Build Scalability: Eugene Yokota on Bringing Bazel Features to sbt 2.0 | EngFlowDemocratizing Build Scalability: Eugene Yokota on Bringing Bazel Features to sbt 2.0 In this interview, Eugene Yokota โ€”a software build expert who spent years maintaining Scala's sbt tool at Lightbend before working with hyperscaled Bazel monorepos at Twitter and Netflixโ€”details his multi-year project to build a Bazel-compatible remote caching system into the newly released sbt 2.0. He explores the mechanics and benefits of Bazel, such as its robust remote caching and test cycle speed, and highlights how these modern, scalable build tools can eliminate CI bottlenecks for growing teams while protecting toolchain security.๐Ÿ“EngFlow Blog

Thursday, July 9, 2026