Welcome to SwedenCpp

Latest blogs, videos, podcasts and releases in one stream

Sunday, May 10, 2026

If this page is useful, please consider your support

Saturday, May 9, 2026

Friday, May 8, 2026

Thursday, May 7, 2026

Partner with Kitware to Accelerate Medical Software Product DevelopmentDeveloping medical software is complex. From early-stage concepts to production-ready systems, organizations must navigate technical challenges, clinical requirements, and regulatory considerations, all while moving quickly and managing risk. Kitware partners with medical device companies, digital health innovators, and research organizations to accelerate the development of advanced medical software products. By combining deep domain expertise with open source platforms and advanced visualization technologies, we help teams move efficiently from concept to deployable solutions.📝Kitware Inc
Project-Specific Build Optimizations with GitHub CopilotWe are excited to announce that GitHub Copilot build performance for Windows now supports project-specific builds! Available in the latest Visual Studio Insiders, you can target a single MSBuild project or CMake target instead of analyzing your entire solution. For game developers and teams working with large codebases, this eliminates the need to wait for […] The post Project-Specific Build Optimizations with GitHub Copilot appeared first on C++ Team Blog .📝C++ Team Blog

Wednesday, May 6, 2026

Qt Design Studio 4.8.2 ReleasedQt Design Studio 4.8.2 Is Here! Following our 4.8.1 release , which introduced the Qt Design Studio AI Assistant in beta, we are back with a significant evolution of that feature, along with a few other updates. The 4.8.1 release laid the groundwork, a prompt-based tool that could generate QML from a natural language description or an image. That was a strong foundation, and the feedback we received helped shape where we took it next. In 4.8.2, the assistant has been rebuilt around a fundamentally more powerful architecture, and the difference in what you can accomplish with it is substantial. Qt Design Studio Goes Agentic With 4.8.2, Qt Design Studio takes a major step forward by introducing a fully agentic AI Assistant powered by the Model Context Protocol (MCP), an open standard for connecting AI models to external tools and data sources. This shift transforms the assistant from a passive helper into an active collaborator. Instead of working on a single file, it now understands your entire project structure and can operate across it using a rich set of MCP tools: reading files, creating components, modifying existing ones, and more. When you describe a goal, the assistant enters an agentic loop. It plans the task, selects the appropriate tools, executes them, evaluates the results, and continues iterating until the objective is complete. Every step is logged in the chat, so you can follow the process. Built on MCP, the assistant is designed to be extensible and future-proof, enabling integrations with external MCP server. The assistant supports leading models from Anthropic, Google, and OpenAI, and you can switch between providers within the same conversation. The agentic AI assistant is available to all Qt Design Studio users, we encourage you to try it out and share your feedback. Agentic AI at Work: Medical UI demo Created from a Single Prompt Qt Kit Updated to 6.8.7 This release also bumps the bundled Qt Kit from 6.8.5 to 6.8.7, picking up the latest stability and maintenance improvements from the Qt 6.8 series. Further Information Our change log contains the full list of fixes and improvements included in this release. If you run into any bugs or usability issues, please report them in the issue tracker — your feedback helps us improve every release. New to Qt Design Studio? Explore the online documentation or head to the learning portal to get up to speed. We look forward to hearing what you build with the new agentic assistant!📝Qt Blog

Tuesday, May 5, 2026

Construct with Collaborators, Call with Work@media only screen and (max-width: 600px) { .body { overflow-x: auto; } .post-content table, .post-content td { width: auto !important; white-space: nowrap; } } This article was adapted from a Google Tech on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office. By Shahar Roth Classes require various objects and parameters to function. The "Construct with Collaborators, Call with Work" guideline can help you construct effective inputs: Use the constructor for collaborators—the dependencies that establish the object’s identity. Collaborators stay with the object for its lifetime to enable it to fulfill its ongoing duties. Pass work—the parameters that change with each interaction—to methods. Unique to each call, these inputs provide the specific data needed for an operation such as a file path or database query. Consider a ReportGenerator that needs a database, a formatter, and a date range to generate a report. The database and formatter , as collaborators, are injected via the constructor, while dateRange , which varies per report generation, is passed as a method parameter to the generate method: class ReportGenerator { private final Database database ; private final Formatter formatter ; // database and formatter are passed as collaborators. ReportGenerator(Database database , Formatter formatter ) { this. database = database ; this. formatter = formatter ; } // dateRange is passed as a parameter. Report generate(Range dateRange ) { return formatter .format( database .getRecords( dateRange )); } } A single ReportGenerator object can generate multiple reports with different date ranges: ReportGenerator generator = new ReportGenerator( database , formatter ); Report report1 = generator.generate( dateRange1 ); Report report2 = generator.generate( dateRange2 ); Following the "Construct with Collaborators, Call with Work" guideline promotes : Reusability: Enables instances to be used for multiple, distinct operations. Testability: Separates dependency setup from business logic. Cleaner code: Hides implementation dependencies from the object’s users. Predictable behavior: Locks in dependencies at creation time. Note that the definition of "collaborator" versus "work" depends on the object's identity. For example, a RequestMessage could be a collaborator for a RequestHandler if the handler operates on a single request, or work if the handler processes different requests with each method call.📝Google Testing Blog
Introducing the QML Profiler Skill for Agentic DevelopmentInstead of a painstaking row-by-row or slow flame graph reviews, the QML profiler skill for agentic development allows developers to delegate code performance profiling to AI agents. The skill guides the developer through the workflow, triggers the QML profiler, crunches through the resulting raw data, presents the performance bottlenecks in a concise report, and suggests improvements. The skill targets 2D Qt Quick applications and supports four profiling modes — rendering, logic, memory, and full. It can also analyze an existing trace file directly, without re-running the application, for example, if the performance trace has been run on the target hardware. Video: QML profiling of shopping list app in Claude Code CLI (Some sequences are shortened or accelerated)📝Qt Blog
ELF’s ways to combine potentially non-unique objectsPreviously [I wrote](/blog/2026/04/24/define-static-array/): > [Template parameter objects of array type] are permitted to overlap or be > coalesced, just like `initializer_list`s and string literals. Clang trunk > isn't smart enough to coalesce potentially non-unique objects [but] > GCC, once it implements `define_static_array`, will presumably make them the same. Well, GCC 16 has an experimental implementation of `define_static_array` (compile with `g++ -std=c++26 -freflection`), and it does _not_ coalesce template parameter objects of array type in the way I expected. Digging deeper into why not, I learned that there are at least three ways compilers and linkers (on ELF — that is, non-Windows — platforms) conspire to "merge" potentially non-unique objects: * Merging at the compiler level (for `initializer_list` backing arrays) * Sections with `SHF_MERGE` (for string literals and backing arrays) * Sections with `SHF_GROUP`, a.k.a. COMDAT sections (for inline variables)📝Arthur O’Dwyer
Introducing conan-py-build: Build Python Wheels with ConanPackaging Python extensions that contain native C or C++ code has come a long way. PEP 517 defined a contract between Python build frontends ( pip , build , uv ) and the build backend that produces the wheel. That standard is what makes it possible today to connect a CMakeLists.txt to a pyproject.toml , declare a backend, and let pip wheel . drive the build. The C/C++ dependency layer is a different story. Somewhere between pyproject.toml and CMakeLists.txt , a find_package(OpenSSL) has to resolve. In practice, most projects solve that outside the wheel build: through system packages, vendored source trees, FetchContent or a separate native package manager install step. That means a separate step to manage before the Python build, often duplicated across CI configurations and developer setups. Today, we are happy to introduce conan-py-build , a PEP 517 build backend that brings Conan’s C/C++ dependency management directly into the Python wheel build. The project is currently in beta and under active development. We are releasing it now to gather early feedback, and we would love for you to try it and tell us what you think. What is conan-py-build? conan-py-build is a build backend for Python packages that contain native C/C++ extensions. You declare it in pyproject.toml , provide a conanfile.py that describes the C/C++ build and its dependencies, and build wheels through standard Python packaging commands such as pip wheel . . When a build runs, conan-py-build : Resolves the C/C++ dependency graph through Conan, downloading precompiled binaries where available and building the rest from source Prepares the build toolchain through the corresponding Conan generators Builds the extension using your project’s build system When the extension links against shared libraries, copies those runtime dependencies next to the extension module and patches RPATH on Linux and macOS where applicable Packages the result into a standard Python wheel Because it is a PEP 517 backend, it plugs into pip , build , and uv directly, and fits into cibuildwheel -based CI workflows for multi-platform builds. A minimal example Let’s build a tiny Python package that exposes a single function, greet(name) , which prints a colored greeting to the terminal. We’ll use CMake for the native build, pybind11 for the Python bindings, and {fmt} as a dependency pulled in through Conan. The same setup extends to other build systems like Meson or Autotools. The project layout: mypackage/ ├── pyproject.toml ├── conanfile.py ├── CMakeLists.txt └── src/ ├── mypackage/ │ └── __init__.py └── mypackage.cpp pyproject.toml declares the build backend and the project metadata: [build-system] requires = ["conan-py-build"] build-backend = "conan_py_build.build" [project] name = "mypackage" version = "0.1.0" conanfile.py describes the C/C++ side: its dependencies ( pybind11 and fmt ) and how they are built and packaged. from conan import ConanFile from conan.tools.cmake import CMake , cmake_layout class MyPackageConan ( ConanFile ): settings = "os" , "compiler" , "build_type" , "arch" generators = "CMakeToolchain" , "CMakeDeps" def layout ( self ): cmake_layout ( self ) def requirements ( self ): self . requires ( "pybind11/3.0.1" ) self . requires ( "fmt/12.1.0" ) def build ( self ): cmake = CMake ( self ) cmake . configure () cmake . build () def package ( self ): cmake = CMake ( self ) cmake . install () CMakeLists.txt builds the extension against pybind11 and fmt and installs the resulting module into the Python package directory so the backend picks it up when assembling the wheel: cmake_minimum_required ( VERSION 3.15 ) project ( mypackage LANGUAGES CXX ) set ( PYBIND11_FINDPYTHON ON ) find_package ( pybind11 CONFIG REQUIRED ) find_package ( fmt CONFIG REQUIRED ) pybind11_add_module ( _core src/mypackage.cpp ) target_link_libraries ( _core PRIVATE fmt::fmt ) install ( TARGETS _core DESTINATION mypackage ) The C++ source defines greet(name) using fmt’s color support and exposes it as a compiled _core module: #include #include #include void greet ( const std :: string & name ) { fmt :: print ( fmt :: fg ( fmt :: color :: green ), "Hello, {}! \n " , name ); } PYBIND11_MODULE ( _core , m ) { m . def ( "greet" , & greet ); } And src/mypackage/__init__.py re-exports it so callers see mypackage.greet : from mypackage._core import greet __all__ = [ "greet" ] With that in place, building the wheel is the standard Python packaging command: $ pip wheel . -w dist/ Conan resolves pybind11 and fmt from Conan Center Index, CMake compiles the extension against them, and you get a platform-specific wheel in dist/ . Install it and try it: $ pip install dist/mypackage- * .whl $ python -c "import mypackage; mypackage.greet('world')" Hello, world! You should see Hello, world! printed in green. More examples: the repo has nanobind bindings, shared library dependencies, C++ sources fetched at build time, and a full multi-platform cibuildwheel setup for Linux, macOS, and Windows. What conan-py-build brings Some of the advantages of bringing Conan into the wheel build: One build entry point. The usual pip wheel . command can drive both the Python packaging step and the native C/C++ dependency/build step. Conan Center. A large catalog of C/C++ libraries with recipes tested across a broad compiler and OS matrix. Binary caching. Compiled dependencies are reused across builds and CI runs via the Conan cache or a shared remote, rebuilt only when settings change. Profiles and lockfiles. Profiles define the native build configuration of each wheel (compiler, architecture, C++ standard, dependency options), and lockfiles pin the graph for reproducible builds. Shared library handling. Conan-managed runtime libraries are deployed next to the extension module, and RPATH is adjusted on Linux and macOS where applicable. Conclusions conan-py-build pulls the C/C++ dependency layer inside the PEP 517 build so the Python build and the C/C++ build are one problem, not two. If you have been maintaining a separate dependency step alongside your Python packaging, it is worth a look. Check out the documentation and browse the examples . conan-py-build is still in beta and available on PyPI . If something does not work, or there is a workflow you want supported, please open an issue on GitHub and let us know where it fits, or where it does not yet. Looking forward to your feedback.📝Conan C/C++ Package Manager Blog

Monday, May 4, 2026

Kitware Awarded $4M DARPA SABER Contract to Evaluate AI-Enabled Battlefield SystemsClifton Park, NY — May 4, 2026 — Kitware has been awarded a two-year, $4 million contract from the Defense Advanced Research Projects Agency (DARPA), through its Information Innovation Office (I2O), as part of the Securing Artificial Intelligence for Battlefield Effective Robustness (SABER) program. The effort will focus on developing software and participating in field tests to evaluate the resilience of AI-enabled battlefield systems against external threats.📝Kitware Inc
Giving Copilot more C++ context using custom instructions in VS CodeIn February, we announced how GitHub Copilot can now use C++ symbol context and CMake build configuration awareness to deliver smarter suggestions in Visual Studio Code. Today, we’re excited to share new ways to further enhance your C++ development experience with Copilot and get the most out of the language-driven suggestions, by leveraging custom instructions […] The post Giving Copilot more C++ context using custom instructions in VS Code appeared first on C++ Team Blog .📝C++ Team Blog
Introducing the Qt Code Review Skills for Agentic Code ReviewReviewing, auditing, or sanity-checking code usually means running separate linters, reading through checklists, and manually verifying Qt-specific patterns across dozens of files. The Qt code review skills help developers to automate part of this code review phase. Developers avoid a laborious manual walkthrough of every file, with the AI agent running a deterministic linter followed by six parallel deep-analysis agents and surfacing real issues with mitigations in a few minutes. AI-Powered Code Reviews with Reliable Results📝Qt Blog