Welcome to SwedenCpp

Latest blogs, videos, podcasts and releases in one stream

Monday, September 28, 2026

Framatome Intercontrôle – Custom Developments to Optimize Non Destructive Testing Procedures Using a Robotic ArmAbout Framatome Intercontrôle Intercontrôle is a subsidiary of Framatome, specializing in automated Non Destructive Testing (NDT), in particular for safety-critical components of the primary circuits in nuclear reactors. It has been a leader in this field of activity for more than 50 years. They develop, qualify, and operate their inspection equipment on-site. The team therefore […]📝Kitware Inc
Practical Testing: 43 - A performance tweakThis is the next in a series of blog posts, called “Practical Testing”, about testing real-world, multithreaded, code. Code that is in use for a long time goes through various evolutionary changes. The code that we feature in this series of articles is often the beating heart of server systems that are built with The Server Framework. Our many clients have varying performance requirements and changes for one client eventually feed back into the framework that is used by all of our clients.📝Rambling Comments - Len Holgate's blog
Using C++17 std::optionalLet’s take a pair of two types - what can you do with such composition? In this article, I’ll describe std::optional - a helper “vocabulary” type added in C++17. It’s a wrapper that either contains a value of your type or is empty. Let’s see where it can be useful and how you can use it. Updated in September 2026 with C++20, C++23, and C++26 changes. Intro By adding the boolean flag to other types, you can achieve a thing called “nullable types”. As mentioned, the flag is used to indicate whether the value is available or not. Such wrapper represents an object that might be empty in an expressive way (so not via comments :)) While you can achieve “null-ability” by using unique values (-1, infinity, nullptr ), it’s not as clear as the separate wrapper type. Alternatively, you could even use std::unique_ptr and treat the empty pointer as not initialized - this works, but comes with the cost of allocating memory for the object. Optional types - that come from functional programming world - bring type safety and expressiveness. Most of other languages have something similar: for example std::option in Rust, Optional in Java, Data.Maybe in Haskell. std::optional was added in C++17 and brings a lot of experience from boost::optional that was available for many years. Since C++17 you can just #include and use the type. Such wrapper is still a value type (so you can copy it, via deep copy). What’s more, std::optional doesn’t need to allocate any memory on the free store. std::optional is a part of C++ vocabulary types along with std::any , std::variant and std::string_view . When to use Usually, you can use an optional wrapper in the following scenarios: If you want to represent a nullable type nicely. Rather than using unique values (like -1 , nullptr , NO_VALUE or something) For example, user’s middle name is optional. You could assume that an empty string would work here, but knowing if a user entered something or not might be important. With std::optional you get more information. Return a result of some computation (processing) that fails to produce a value and is not an error. For example finding an element in a dictionary: if there’s no element under a key it’s not an error, but we need to handle the situation. To perform lazy-loading of resources. For example, a resource type has no default constructor, and the construction is substantial. So you can define it as std::optional (and you can pass it around the system), and then load only if needed later. To pass optional parameters into functions. I like the description from boost optional which summarizes when we should use the type: From the boost::optional documentation: When to use Optional It is recommended to use optional in situations where there is exactly one, clear (to all parties) reason for having no value of type T , and where the lack of value is as natural as having any regular value of T While sometimes the decision to use optional might be blurry, you shouldn’t use it for error handling. As it best suits the cases when the value is empty and it’s a normal state of the program. Basic Example Here’s a simple example of what you can do with optional: std :: optional std :: string > UI :: FindUserNick () { if ( nick_available ) return { mStrNickName }; return std :: nullopt ; // same as return { }; } // use: std :: optional std :: string > UserNick = UI -> FindUserNick (); if ( UserNick ) Show ( * UserNick ); In the above code we define a function that returns optional containing a string. If the user’s nickname is available, then it will return a string. If not, then it returns nullopt . Later we can assign it to an optional and check (it converts to bool ) if it contains any value or not. Optional defines operator* so we can easily access the contained value. In the following sections you’ll see how to create std::optional , operate on it, pass around and even what is the performance cost you might want to consider. The C++17 Series This article is part of my series about C++17 Library Utilities. Here’s the list of the other topics that I’ll cover: Refactoring with std::optional Using std::optional (this post) Error handling and std::optional About std::variant About std::any In place construction for std::optional , std::variant and std::any std::string_view Performance C++17 string searchers & conversion utilities Working with std::filesystem Even more: Show me your code: std::optional A Wall of Your std::optional Examples Menu Class - Example of Modern C++17 STL features Resources about C++17 STL: C++17 In Detail by Bartek! C++17 - The Complete Guide by Nicolai Josuttis C++ Fundamentals Including C++ 17 by Kate Gregory Practical C++14 and C++17 Features - by Giovanni Dicanio C++17 STL Cookbook by Jacek Galowicz OK, so let’s move to std::optional . std::optional Creation There are several ways to create std::optional : // empty: std :: optional int > oEmpty ; std :: optional float > oFloat = std :: nullopt ; // direct: std :: optional int > oInt ( 10 ); std :: optional oIntDeduced ( 10 ); // deduction guides // make_optional auto oDouble = std :: make_optional ( 3.0 ); auto oComplex = make_optional std :: complex double >> ( 3.0 , 4.0 ); // in_place std :: optional std :: complex double >> o7 { std :: in_place , 3.0 , 4.0 }; // will call vector with direct init of {1, 2, 3} std :: optional std :: vector int >> oVec ( std :: in_place , { 1 , 2 , 3 }); // copy/assign: auto oIntCopy = oInt ; As you can see in the above code sample, you have a lot of flexibility with the creation of optional. It’s very simple for primitive types and this simplicity is extended for even complex types. The in_place construction is especially interesting, and the tag std::in_place is also supported in other types like any and variant . For example, you can write: // https://godbolt.org/g/FPBSak struct Point { Point ( int a , int b ) : x ( a ), y ( b ) { } int x ; int y ; }; std :: optional Point > opt { std :: in_place , 0 , 1 }; // vs std :: optional Point > opt {{ 0 , 1 }}; This saves the creation of a temporary Point object. I’ll address std::in_place later in a separate post, so stay tuned. Returning std::optional If you return an optional from a function, then it’s very convenient to return just std::nullopt or the computed value. std :: optional std :: string > TryParse ( Input input ) { if ( input . valid ()) return input . asString (); return std :: nullopt ; } In the above example you can see that I return std::string computed from input.asString() and it’s wrapped in optional . If the value is unavailable then you can just return std::nullopt . Of course, you can also declare an empty optional at the beginning of your function and reassign if you have the computed value. So we could rewrite the above example as: std :: optional std :: string > TryParse ( Input input ) { std :: optional std :: string > oOut ; // empty if ( input . valid ()) oOut = input . asString (); return oOut ; } It probably depends on the context which version is better. I prefer short functions, so I’d chose the first option (with multiple returns). Accessing The Stored Value Probably the most important operation for optional (apart from creation) is the way how you can fetch the contained value. There are several options: operator* and operator-> - similar to iterators. Accessing an empty optional is undefined behavior in C++17–23. C++26 adds checks in hardened implementations; see the update section below. value() - returns the value, or throws std::bad_optional_access value_or(defaultVal) - returns the value if available, or defaultVal otherwise. To check if the value is present you can use has_value() method or just check if (optional) as optional is automatically converted to bool . Here’s an example: // by operator* std :: optional int > oint = 10 ; std :: cout "oint " * opt1 '\n' ; // by value() std :: optional std :: string > ostr ( "hello" ); try { std :: cout "ostr " ostr . value () '\n' ; } catch ( const std :: bad_optional_access & e ) { std :: cout e . what () " \n " ; } // by value_or() std :: optional double > odouble ; // empty std :: cout "odouble " odouble . value_or ( 10.0 ) '\n' ; So the most useful way is probably just to check if the value is there and then access it: // compute string function: std :: optional std :: string > maybe_create_hello (); // ... if ( auto ostr = maybe_create_hello (); ostr ) std :: cout "ostr " * ostr '\n' ; else std :: cout "ostr is null \n " ; std::optional Operations Let’s see what are other operations on the type: Changing the value If you have existing optional object, then you can easily change the contained value by using several operations like emplace , reset , swap , assign. If you assign (or reset) with a nullopt then if the optional contains a value its destructor will be called. Here’s a little summary: #include #include #include class UserName { public : explicit UserName ( const std :: string & str ) : mName ( str ) { std :: cout "UserName::UserName( \' " ; std :: cout mName " \' ) \n " ; } ~ UserName () { std :: cout "UserName::~UserName( \' " ; std :: cout mName " \' ) \n " ; } private : std :: string mName ; }; int main () { std :: optional UserName > oEmpty ; // emplace: oEmpty . emplace ( "Steve" ); // calls ~Steve and creates new Mark: oEmpty . emplace ( "Mark" ); // reset so it's empty again oEmpty . reset (); // calls ~Mark // same as: //oEmpty = std::nullopt; // assign a new value: oEmpty . emplace ( "Fred" ); oEmpty = UserName ( "Joe" ); } The code is available here: @Coliru Comparisons std::optional allows you to compare contained objects almost “normally”, but with a few exceptions when the operands are nullopt . See below: #include #include int main () { std :: optional int > oEmpty ; std :: optional int > oTwo ( 2 ); std :: optional int > oTen ( 10 ); std :: cout std :: boolalpha ; std :: cout ( oTen > oTwo ) " \n " ; std :: cout ( oTen oTwo ) " \n " ; std :: cout ( oEmpty oTwo ) " \n " ; std :: cout ( oEmpty == std :: nullopt ) " \n " ; std :: cout ( oTen == 10 ) " \n " ; } The above code generates: true // (oTen > oTwo) false // (oTen The code is available here: @Coliru Examples of std::optional Here are two a few longer examples where std::optional fits nicely. User name with an optional nickname and age #include #include class UserRecord { public : UserRecord ( const std :: string & name , std :: optional std :: string > nick , std :: optional int > age ) : mName { name }, mNick { nick }, mAge { age } { } friend std :: ostream & operator ( std :: ostream & stream , const UserRecord & user ); private : std :: string mName ; std :: optional std :: string > mNick ; std :: optional int > mAge ; }; std :: ostream & operator ( std :: ostream & os , const UserRecord & user ) { os user . mName ' ' ; if ( user . mNick ) { os * user . mNick ' ' ; } if ( user . mAge ) os "age of " * user . mAge ; return os ; } int main () { UserRecord tim { "Tim" , "SuperTim" , 16 }; UserRecord nano { "Nathan" , std :: nullopt , std :: nullopt }; std :: cout tim " \n " ; std :: cout nano " \n " ; } The code is available here: @Coliru Parsing ints from the command line #include #include #include std :: optional int > ParseInt ( char * arg ) { try { return { std :: stoi ( std :: string ( arg )) }; // or from_chars... } catch (...) { std :: cout "cannot convert \' " arg " \' to int! \n " ; } return { }; } int main ( int argc , char * argv []) { if ( argc >= 3 ) { auto oFirst = ParseInt ( argv [ 1 ]); auto oSecond = ParseInt ( argv [ 2 ]); if ( oFirst && oSecond ) { std :: cout "sum of " * oFirst " and " * oSecond ; std :: cout " is " * oFirst + * oSecond " \n " ; } } } The code is available here: @Coliru The above code uses optional to indicate if we performed the conversion or not. Note that we in fact converted exceptions handling into optional, so we skip the errors that might appear. This might be “controversial” as usually, we should report errors. C++17 also offers std::from_chars , which parses numbers without throwing exceptions or allocating memory. See my article C++ String Conversion: Exploring std::from_chars in C++17 to C++26 for examples, including a parser that returns std::optional . Other examples Representing other optional entries for your types. Like in the example of a user record. It’s better to write std::optonal rather than use a comment to make notes like // if the 'key is 0x7788 then it's empty or something :) Return values for Find*() functions (assuming you don’t care about errors, like connection drops, database errors or something) See more in: A Wall of Your std::optional Examples - C++ Stories Performance & Memory consideration When you use std::optional you’ll pay with increased memory footprint. At least one extra byte is needed. Conceptually your version of the standard library might implement optional as: template typename T > class optional { bool _initialized ; std :: aligned_storage_t sizeof ( T ), alignof ( T ) > _storage ; public : // operations }; In short optional just wraps your type, prepares a space for it and then adds one boolean parameter. This means it will extend the size of your Type according do the alignment rules. There was one comment about this construction : “And no standard library can implement optional this way (they need to use a union, because constexpr)”. So the code above is only to show an example, not real implementation. Alignment rules are important as The standard defines: Class template optional [optional.optional]: The contained value shall be allocated in a region of the optional storage suitably aligned for the type T. For example: // sizeof(double) = 8 // sizeof(int) = 4 std :: optional double > od ; // sizeof = 16 bytes std :: optional int > oi ; // sizeof = 8 bytes While bool type usually takes only one byte, the optional type need to obey the alignment rules and thus the whole wrapper is larger than just sizeof(YourType) + 1 byte . For example, if you have a type like: struct Range { std :: optional double > mMin ; std :: optional double > mMax ; }; it will take more space than when you use your custom type: struct Range { bool mMinAvailable ; bool mMaxAvailable ; double mMin ; double mMax ; }; In the first case, we’re using 32 bytes! The second version is 24 bytes. Test code using Compiler Explorer Here’s a great description about the performance and memory layout taken from boost documentation: Performance considerations - 1.67.0 . And in Efficient optional values | Andrzej’s C++ blog the author discusses how to write a custom optional wrapper that might be a bit faster I wonder if there’s a chance to do some compiler magic and reuse some space and fit this extra “initialized flag” inside the wrapped type. So no extra space would be needed. Migration from boost::optional std::optional was adapted directly from boost::optional , so you should see the same experience in both versions. Moving from one to another should be easy, but of course, there are little differences. In the paper: N3793 - A proposal to add a utility class to represent optional objects (Revision 4) - from 2013-10-03 I’ve found the following table (and I tried to correct it when possible with the current state). aspect std::optional boost::optional (as of 1.67.0 ) Move semantics yes no yes in current boost noexcept yes no yes in current boost hash support yes no a throwing value accessor yes yes literal type (can be used in constexpr expressions) yes no in place construction `emplace`, tag `in_place` emplace() , tags in_place_init_if_t , in_place_init_t , utility in_place_factory disengaged state tag nullopt none optional references C++17–23: no; C++26: yes ( optional ) yes conversion from optional to optional yes yes explicit convert to ptr ( get_ptr ) no yes deduction guides yes no Special case: optional and optional While you can use optional on any type you need to pay special attention when trying to wrap boolean or pointers. std::optional ob - what does it model? With such construction you basically have a tri-state bool. So if you really need it, then maybe it’s better to look for a real tri-state bool like boost::tribool . Whet’s more it might be confusing to use such type because ob converts to bool if there’s a value inside and *ob returns that stored value (if available). Similarly you have a similar confusion with pointers: // don't use like that! only an example! std :: optional int *> opi { new int ( 10 ) }; if ( opi && * opi ) { std :: cout ** opi std :: endl ; delete * opi ; } if ( opi ) std :: cout "opi is still not empty!" ; The pointer to int is naturally “nullable”, so wrapping it into optional makes it very hard to use. Changes in C++20, C++23, and C++26 C++17 was published a long time ago, let’s find out how std::optional evolved over the recent years: C++20: Comparisons and constexpr C++20 adds operator (spaceship) for optionals. For example: #include #include constexpr std :: optional int > empty ; constexpr std :: optional int > two = 2 ; constexpr std :: optional int > ten = 10 ; static_assert (( two ten ) 0 ); // compares the stored values static_assert (( empty two ) 0 ); // empty comes before a value static_assert (( empty empty ) == 0 ); The stored types must support the required comparisons. See the C++20 specification . C++17 already allowed constructing an optional from a value at compile time. P2231R1 added missing constexpr support for operations like emplace() , reset() , assignment, swapping, and converting constructors. It was adopted during C++23 work as a defect report against C++20 . For example, with that change we can write: #include constexpr int compute () { std :: optional int > value ; value . emplace ( 42 ); value . reset (); return value . value_or ( 7 ); } static_assert ( compute () == 7 ); See @Compiler Explorer The operations on the stored type must also work at compile time. C++23: Monadic operations C++23 adds three functions for chaining operations on optionals ( P0798R8 ): transform() applies a function to the stored value and wraps the result in an optional. and_then() calls a function that already returns an optional, without adding another optional around it. or_else() calls a fallback function when the optional is empty. The function returns an optional of the same type. transform() and and_then() skip the function call when the optional is empty. These functions do not catch exceptions. I covered them with examples in a separate article: How to Use Monadic Operations for std::optional in C++23 . C++23 also adds std::expected . Consider it when the caller needs to know why an operation failed, rather than just whether a value is available. C++26: Range support C++26 adds begin() and end() and makes optional a ranges view ( P3168R2 ). A loop over an optional runs once if there’s a value, or not at all if it’s empty: std :: optional int > value = 42 ; for ( int x : value ) std :: cout x '\n' ; // prints 42 once This also lets us use std::views::join on a range of optionals to visit the values and skip empty entries. C++26: Optional references C++26 adds std::optional ( P2988R12 ). It can refer to an existing object or be empty: int first = 10 ; int second = 20 ; std :: optional int &> ref { first }; * ref = 15 ; // changes first ref . emplace ( second ); // now refers to second * ref = 25 ; // changes second Notice that emplace() changes which object we refer to, while writing through *ref changes the object itself. The optional does not own the object or keep it alive. C++26: Hardened access With a hardened standard library, operator* and operator-> check that the optional has a value before accessing it ( P3471R4 ). Without hardening, accessing an empty optional this way still has undefined behavior. Use value() if you want an exception when the optional is empty. For examples and compiler options, see my C++26: Standard Library Hardening Experiments . Support for these C++26 features depends on your compiler and standard library. Wrap up Uff… ! it was a lot of text about optional, but still it’s not all :) Yet, we’ve covered the basic usage, creation and operations of this useful wrapper type. I believe we have a lot of cases where optional fits perfectly and much better than using some predefined values to represent nullable types. I’d like to remember the following things about std::optional : std::optional is a wrapper type to express “null-able” types. std::optional won’t use any dynamic allocation std::optional contains a value or it’s empty use operator * , operator-> , value() or value_or() to access the underlying value. std::optional is implicitly converted to bool so that you can easily check if it contains a value or not. In the next article I’ll try to explain error handling and why optional is maybe not the best choice there. I’d like to thank Patrice Roy ( @PatriceRoy1 ), Jacek Galowicz ( @jgalowicz ) and Andrzej Krzemienski ( akrzemi ) for finding time do do a quick review of this article!📝C++ Stories

If this page is useful, please consider donating a coffee

Sunday, September 27, 2026

Saturday, September 26, 2026

Friday, September 25, 2026

Thursday, September 24, 2026

Remembering Johannes DoerfertIt is with great sadness that we share the news of the passing of Johannes Doerfert, on September 17, 2026, at the age of 36, after a battle with cancer. Johannes was one of the most prolific and respected contributors to the LLVM compiler project, and his loss will be deeply felt. Johannes was born on November 5, 1989. He earned his Ph.D. in computer science from Saarland University in Saarbrücken, Germany, in 2018, where his research focused on applying polyhedral compiler technologies to low-level code. He had been an active LLVM contributor since 2014, working in the compiler design lab of Prof. Sebastian Hack, and became a core developer on the Polly polyhedral-optimization project as early as 2012. Over the following decade, Johannes built a career at the intersection of compiler research and high-performance computing, most recently as a researcher focused on OpenMP, LLVM, and parallel program optimization. Contributions to LLVM Johannes’s worked on many parts of the LLVM Project, and these are just a few of his contributions: The Attributor framework. Johannes designed and championed the Attributor, LLVM’s versatile inter-procedural fixpoint iteration framework for deducing and propagating function and argument attributes across a program. He introduced it to the community at the 2019 LLVM Developers’ Meeting, and it has since become an important piece of LLVM’s interprocedural optimization infrastructure. OpenMP and GPU offloading. Johannes became LLVM’s code owner for OpenMP target offloading in 2021, leading the compiler and runtime support that lets OpenMP programs run efficiently on GPUs across NVIDIA, AMD, and Intel hardware. His work spanned the OpenMP runtime, just-in-time compilation and link-time optimization for target offloading, and techniques for near-zero-overhead GPU execution. Polly and polyhedral optimization. Early in his career, Johannes was a core developer of Polly, LLVM’s polyhedral loop optimization infrastructure, and published research on polyhedral scheduling in the presence of reductions and on optimistic loop optimization. He authored or co-authored dozens of papers on compiler optimization, automatic differentiation of GPU kernels, performance portability, and OpenMP. Community Building Johannes helped organize EuroLLVM 2017 in Saarbrücken, Germany, the LLVM-HPC workshop at CGO from 2017 onward, and the LLVM events at ISC starting in 2019, helping join together the LLVM and HPC communities. He was frequently in attendance at the LLVM Developers’ Meeting Newcomer and Community.o sessions. He welcomed newcomers to the LLVM Developers’ Meetings and shared his advice and wisdom on how to get more involved in the project. Johannes also held LLVM office hours on a weekly basis, where he answered questions on OpenMP, LLVM-IR, interprocedural optimizations, Attributor, workshops, research, and more. Mentoring the Next Generation Johannes was a Google Summer of Code mentor for LLVM for several years and helped student contributors on various projects. Here are just a few: 2016 Polly as an Analysis Pass in LLVM 2019 Improve (function) attribute inference (with Brian Homerding) Improve (function) attribute inference - 2 (with Brian Homerding) Generation of Annotated Sources (with Brian Homerding) 2020 Improve Parallelism-Aware Analyses and Optimizations (with Jon Chesterfield) Advanced Heuristics for Ordering Compiler Optimization Passes (with EJ Park and Giorgis Georgakoudis) Improve inter-procedural analyses and optimizations (with Brian Homerding) Advanced Heuristics for Ordering Compiler Optimization Passes - 2 (with EJ Park and Giorgis Georgakoudis) Latency Hiding for Host to Device Memory Transfers (with Jon Chesterfield) Improve inter-procedural analyses and optimizations - 2 (with Brian Homerding) Deduce attributes for non-exact functions (with Brian Homerding) 2021 Learning Loop Transformation Heuristics (with Mircea Trofin) Integrate custom derivatives of Numerical Computing routines like BLAS and Eigen into Enzyme (with William Moses and Vassil Vassilev) Improving OpenMP code generation with prediction of runtime parameters (with Jon Chesterfield) Integrate Enzyme into Rust to Provide High-performance Differentiation in Rust (with William Moses) Improve inter-procedural analyses and optimizations (with Jon Chesterfield) Use official isl C++ bindings for polly (with Michael Kruse) Integrating Enzyme into Rust (with William Moses) 2022 Non-Determinacy based optimizations in Parallel Programs (with William Moses) Learning loop transformation policy and its effect on RISC-V (with Mircea Trofin) 2023 Machine Learning Guided Ordering of Compiler Optimization Passes (with Tarindu Jayatilaka and Mircea Trofin) 2024 The 1001 Thresholds in LLVM (with Jan Hückelheim and William Moses) GPU Libc Benchmarking (with Joseph Huber) Statistical Analysis of LLVM-IR Compilation (with Aiden Grossman) 2025 Improve Rust-Enzyme Reliability and Compile Times (with Manuel Drehwald and Kevin Sala) LLVM Compiler Remarks Visualization Tool for Offloading (with Jose M Monsalve Diaz and Kevin Sala) A Decade at the Podium Besides the countless code contributions, mentorship, and community building, Johannes was a constant presence at US LLVM Developers’ Meetings and EuroLLVM. He spoke at 11 meetings across 11 years (2015–2024) , for at least 26 speaking sessions and even more that he helped author. 2015 — US DevMtg (San Jose) Input Space Splitting for OpenCL Tutorial: Polly - Optimistic Loop Nest Optimizations with Schedule Trees (with Tobias Grosser) 2016 — EuroLLVM (Barcelona) Analyzing and Optimizing your Loops with Polly (with Tobias Grosser) BoF: Polly - Loop Optimization Infrastructure (with Tobias Grosser and Zino Benaissa) 2017 — US DevMtg (San Jose) BoF: Thoughts and State for Representing Parallelism with Minimal IR Extensions in LLVM (with Xinmin Tian, Hal Finkel, Tb Schardl and Vikram Adve) Polyhedral Value & Memory Analysis 2017 — EuroLLVM (Saarbrücken) Co-organizer 2018 — US DevMtg (San Jose) Optimizing Indirections, using abstractions without remorse BoF: Ideal versus Reality: Optimal Parallelism and Offloading Support in LLVM (with Xinmin Tian, Hal Finkel, TB Schardl, and Vikram Adve) 2019 — EuroLLVM (Brussels) Compiler Optimizations for (OpenMP) Target Offloading to GPUs BoF: IPO — Where are we, where do we want to go? (with Kit Barton) 2019 — US DevMtg (San Jose) The Attributor: A Versatile Inter-procedural Fixpoint Iteration Framework Tutorial: The Attributor: A Versatile Inter-procedural Fixpoint Iteration Framework Tutorial: An overview of LLVM Poster: Attributor, a Framework for Interprocedural Information Deduction (with Hideto Ueno and Stefan Stipanovic) 2020 — US DevMtg (virtual) The Present and Future of Interprocedural Optimization in LLVM (with Brian Homerding, Stefanos Baziotis, Stefan Stipanovic, Hideto Ueno, Kuter Dinel, Shinji Okumura, Luofan Chen) (OpenMP) Parallelism-Aware Optimizations (with S. Stipanovic; H. Mosquera; J. Chesterfield; G. Georgakoudis; J. Huber) Tutorial: A Deep Dive into the Interprocedural Optimization Infrastructure (with B. Homerding; S. Baziotis; S. Stipanovic; H. Ueno; K. Dinel; S. Okumura; L. Chen) 2021 — US DevMtg (virtual) Panel: Machine Learning Guided Optimizations in LLVM Optimizing OpenMP GPU Execution in LLVM (with Giorgis Georgakoudis and Joseph Huber) 2022 — US DevMtg (San Jose) Panel: Machine Learning Guided Optimizations (MLGO) in LLVM Panel: High-level IRs for a C/C++ Optimizing Compiler CUDA-OMP — Or, Breaking the Vendor Lock (with Joseph Huber) Thoughts on GPUs as First-Class Citizens 2023 — EuroLLVM (Glasgow) How to run the LLVM-Test Suite on GPUs and what you’ll find OpenMP as GPU Kernel Language 2024 — US DevMtg (Santa Clara) (Offload) ASAN via Software Managed Virtual Memory Johannes Will Be Missed Beyond the commits, the talks, and the papers, those who worked with Johannes remember him as a person full of life and a good sense of humor. He is someone who signed his social media bio simply as “LLVM Developer, OpenMP contributor, Beer drinker, not in this order.” A memorial service will be held on Saturday, October 3, 2026, from 1:00 to 5:00 PM at San Jose Funeral Service in San Jose, California, with a separate service planned in Germany. He is survived by his wife, Xuejin Zhang, his father, Jürgen Doerfert, and other family and friends around the world. In lieu of flowers, his family has asked that those who wish to honor his memory consider a donation to the LLVM Foundation (either through Everloved or directly), the organization whose mission he spent his career supporting and advancing. A very generous donor has agreed to match 50K in donations in honor of Johannes. If you donate directly to the LLVM Foundation via a DAF, please indicate in memory of Johannes Doerfert. More details, and a place to share memories and condolences, can be found on Johannes’s memorial page .📝The LLVM Project Blog
Why Tests Became the Product: A Conversation with Titus Winters | EngFlowWhy Tests Became the Product: A Conversation with Titus Winters A conversation with Titus Winters · Notes From The Fleet series Watch the full interview I sat down with Titus Winters to talk about developer experience and infrastructure at scale. Titus co-wrote Software Engineering at Google ; he is now a Senior Principal Scientist at Adobe. I expected a conversation about build systems. What I got was a line I've been thinking about ever since: "The question is not what can you build with an incredibly fast, 80% accurate tool. It's what can't you build with an infinite army of incredibly fast, 80% accurate tools." An infinite army of 80% accurate tools. That army doesn't have a code generation problem. It has a verification problem. Whether it helps you or buries you depends on the systems that check, integrate, and maintain everything it produces. [![Titus Winters interview](/images/2026-titus-winters/titus-interview.png)](https://youtu.be/YyqgNpNQJwQ?si=FQdLSQxUJXHmn5qz){ class="img-fluid w-100"} Titus Winters on the shift from code generation to verification in the AI era📝EngFlow Blog

Wednesday, September 23, 2026

Canvas2D: WatchUI DemoIn the previous blog post I introduced Canvas2D , the new QML item in Qt 6.12 that lets you paint with JavaScript using the GPU through Qt Canvas Painter. That post was about the API: what it is, how it compares to Qt Quick Canvas and to the QCanvasPainter C++ API , and how fast it is. But that post might have left someone wondering what a real UI built with it could actually look like. So, while testing Canvas2D (and QQEM) in preparation for the Qt 6.12.0 release, I spent a few days building a demo application to give some ideas. WatchUI is a smartwatch demo with six swipeable views, running on a 3D watch model. This is based on the smartwatch demo that was built a while back for the Qt 6.5 release . But the content of the watch screen has been reimplemented using not just QQEM effects but also Canvas2D. The demo looks like this:📝Qt Blog
Hot Reload in Qt 6.12QML Preview We've had a thing called "QML Preview" for a number of years now. You can be forgiven for not having noticed. It's well hidden deep in the guts of Qt Design Studio where it's quietly doing what it does: it runs your design through the qml tool and gets notified when you change some file. Then it re-loads the currently visible scene, without re-starting the process, making your changes visible. This way you get faster turnaround when prototyping different designs.📝Qt Blog
⬢ Distrobox: An In-depth Guide for Developers - Part 1Distrobox gives developers a fast, practical way to work across Linux distributions without the setup time and resource overhead of full virtual machines. This in-depth guide explains how Distrobox builds on OCI containers and tools such as Podman or Docker to create tightly integrated development environments—with access to your home directory, graphical sessions, devices, and host tooling. Learn why it is useful for reproducing distro-specific bugs, testing software on multiple platforms, accessing alternative package repositories, and combining a stable host OS with flexible, disposable userlands.📝KDAB

Tuesday, September 22, 2026

Faster C++ code intelligence for Copilot CLI with Whole Codebase IndexingC++ repositories can contain millions of lines of code spread across deeply connected source files and headers. Without a reusable index, navigating to definitions, finding references, or searching for symbols may require portions of that information to be analyzed again as you move through the repository. C++ code intelligence in GitHub Copilot CLI is now […] The post Faster C++ code intelligence for Copilot CLI with Whole Codebase Indexing appeared first on C++ Team Blog .📝C++ Team Blog