Welcome to SwedenCpp

Latest blogs, videos, podcasts and releases in one stream

Monday, August 17, 2026

If this page is useful, please consider donating a coffee

Sunday, August 16, 2026

No imageCoverage suppression merged into GCCA few days ago I pushed support for coverage suppression in GCC. Sometimes we write very defensive guards, especially in debug builds (like asserts), that are intended to never trigger because they signal a logic bug elsewhere. It’s hard to argue that defensive code and asserts isn’t excellent, but they paradoxically introduce a problem for coverage since we now introduce decisions and code paths that will never be exercised. The new #pragma suppress_coverage and __attribute__((suppress_coverage)) address this problem. GCC could already ignore files for coverage (with -fprofile-filter-files and -fprofile-exclude-files ), but this is more granular. The problem is easily demonstrated with a trivial example. n/m where m == 0 is undefined behaviour and inputs should be sanitized. The assert is there to find the cases when it isn’t. double ratiof ( unsigned int n , unsigned int m ) { assert ( m != 0 ); return ( double ) n / m ; } The assert is really a branch, it expands to something of the effect of if (cond) abort() . Since the abort should never be reached we cannot achieve full coverage. Now, what we could do is to simply ignore these false positives when we analyze the coverage report. The problem is that false positives poison the report and dull our sensitivity to problems, and we don’t detect new or surprising coverage. This is similar to why we want clean compiles, because under a deluge of warnings the real problems don’t stand out. Here’s a slightly more sophisticated example. The comparison function given to qsort has these requirements: comp is a comparison function which returns a negative integer value if the first argument is less than the second, a positive integer value if the first argument is greater than the second and zero if the arguments are equivalent. These properties should be true for all calls to comp for all elements in the array. We want to verify this in our testsuite and can afford the (debug build) performance hit. void qsort ( void * ptr , size_t count , int ( * comp )( const void * , const void * )) { // ... while ( 1 ) { void * x = ptr [ bot ]; void * y = ptr [ top ]; #if defined(DEBUG) int lt = comp ( x , y ); int gt = comp ( y , x ); if ( lt 0 ) assert ( gt > 0 ); if ( lt == 0 ) assert ( gt == 0 ); if ( lt > 0 ) assert ( gt 0 ); #endif } // ... } This would tank the coverage totals, while at the same providing stronger confidence in the provided comp functions and something we want to keep. We can fix the coverage problem with the suppress_coverage pragma: void qsort ( void * ptr , size_t count , int ( * comp )( const void * , const void * )) { // ... while ( 1 ) { void * x = ptr [ bot ]; void * y = ptr [ top ]; #if defined(DEBUG) #pragma suppress_coverage begin int lt = comp ( x , y ); int gt = comp ( y , x ); if ( lt 0 ) assert ( gt > 0 ); if ( lt == 0 ) assert ( gt == 0 ); if ( lt > 0 ) assert ( gt 0 ); #pragma suppress_coverage end #endif } // ... } That’s it, really, and quite intuitive. The code in the suppress_coverage begin / end blocks won’t contribute to total coverage, and the (sub)paths that thread through the suppress_coverage block won’t be counted towards prime path coverage. We can also suppress whole functions using the new __attribute__((suppress_coverage)) (or [[gnu::suppress_coverage]] ) attribute. This is ideal for pure pre/post condition checking functions, but since it disables all coverage for the function it should probably be use sparingly to not suppress the code we do want to cover. __attribute__ (( suppress_coverage )) double ratiof ( unsigned int n , unsigned int m ) { assert ( m != 0 ); // won't count for coverage return ( double ) n / m ; // this won't either } This feature will be released with GCC 17 (spring 2027 probably), but can be backported to earlier releases. This feature was commissioned; Patch can support you in backporting coverage suppression or adding new features.📝patch – Blog

Saturday, August 15, 2026

Friday, August 14, 2026

Thursday, August 13, 2026

Clearer Build Optimization Results with GitHub CopilotWe know that slow builds are a consistent theme in feedback from C++ developers. Your feedback helped us to shape GitHub Copilot build performance for Windows, an agent that can trace your build, find bottlenecks, apply optimizations, and measure the result. When using the agent, the clearest outcome is a straightforward win. The agent changes […] The post Clearer Build Optimization Results with GitHub Copilot appeared first on C++ Team Blog .📝C++ Team Blog
Introducing Photometric ConditionsIntroducing Photometric Conditions A "1000 lm" LED lamp and a "1000 lm" low-pressure sodium lamp do not look equally bright at night. The number on both boxes is a photopic value: it weights the lamp's spectrum with $V(\lambda)$, the spectral sensitivity of the eye's cone cells, which drive vision in daylight. At night, rod cells take over, the sensitivity curve shifts towards blue ($V'(\lambda)$), and the same two lamps deliver roughly 2000 and 250 scotopic lumens respectively. Both figures are luminous fluxes. Both are expressed in lumens. And a program that adds or compares them computes a result that is wrong by up to a factor of eight: cpp auto led = 1000. * lm; // photopic value from the datasheet auto sodium = 250. * lm; // scotopic value from a night-visibility model auto total = led + sodium; // compiles everywhere, means nothing To the best of our knowledge, no units library catches this today, because every one of them (including mp-units until now) models a lumen as a lumen. This post introduces photometric conditions : a way to keep photopic, scotopic, mesopic, and custom quantities in separate quantity hierarchies, so that the mistake above breaks at compile time, while everything the physics does allow keeps working.📝mp-units

Wednesday, August 12, 2026

Digitizing super 8 film yourselfIn our previous post we looked at fixing a super 8 film projector. While watching film with a real projector has its own charm, it is inconvenient to say the least. First of all you make the entire room properly dark or you can't see anything. This is regardless of the fact that the projector bulb is consuming 100 watts of power to show the image. Even if you manage not to burn the film, merely running it through the projector causes wear, scratches and tearing. While film typically ages very well, eventually it will turn into magenta goop or gets eaten by vinegar syndrome . Thus you really want to convert all these films into high quality digital files. There are several companies that offer this service. If you only have a few reels, using those is the smart thing to do. I, on the other hand, have so much material that using a commercial service would cost thousands (possibly tens of thousands) of euros. Fortunately, this is a fairly common problem and there are dozens of existing projects on the Internet to be inspired by. The main technical problem with super 8 film is that it is very small. A sequence of 10 super 8 images is approximately as long as a matchstick. The fact that projectors can display 18 frames per second with sub millimeter registration is an astounding achievement of mechanical engineering. How do they do that? Very difficultly. Many of the DIY solutions start by taking an existing projector and modifying it to run slower. Then you remove the projection lens and aim a digital camera with a macro lens at the gate. This yields incredible results quality-wise but requires a fairly expensive macro lens and typically the modification on the projector is destructive. So that's out. Some more searching eventually lead me to this Github project . The basic idea is simple. Instead of using a projector or trying to replicate a film transport (which proper tension and all that) instead rely on the basic stiffness on film and drive it directly with stepper motor. Film is not aligned mechanically but instead by detecting the sprocket hole with some straightforward machine vision code. Time to fire up the ol' 3D printer and order components. This is what the end result looks like after assembly The thing at the top left that looks like a space cannon prop from a scifi movie is actually a microscope lens. Not only can it do > 1x optical magnification, it does it at a cost of about 25 euros. The downside is noticeable chromatic aberration. The small flat thing on the other end is the Raspberry Pi HQ camera module that can do 4k at 12 bits per channel. The whole thing is run via a single Raspberry Pi 3 with a stepper motor hat. The board at the bottom is used to distribute 12V DC power to the lamp and motors. Before going further, let's just spend some time appreciating just how awesome colors look in this film. Props to the chemical engineers at Kodak. And remember, the original image is about one third of the size of your smallest fingernail. The Github repo says that you probably need to adapt the code to your setup. I basically ended up reimplementing all of it from scratch. In the process I learned that OpenCV has its own GUI toolkit which is both simple (one could even say simplistic) and perfect for this use case. The first attempt took nine hours to process one 3.5 minute reel of film. Then I realized that trying to do 4k on material that physically maxes out at approximately 2k with the processing power of a potato is not a recipe for success. Halving the capture resolution and a few other optimizations brought the runtime down to about one hour per reel. With this, some more custom software for image processing and stabilization coupled with FFmpeg scripts one can start to go through the archive of films. Doing so raises a fair bit of questions. For example: Is that a 3 year old child driving a jury-rigged go-kart on a frozen lake on his own without even wearing a helmet? Yes it is. A bit later an adult drives the car but he is too heavy so the ice cracks under him. No one seems particularly concerned. This may seem strange to us but you have to understand that this was the very early 70s. The concept of safety had not been invented yet.📝Nibble Stew

Tuesday, August 11, 2026