Welcome to SwedenCpp

Latest blogs, videos, podcasts and releases in one stream

Saturday, June 6, 2026

If this page is useful, please consider donating a coffee

Friday, June 5, 2026

I'm Allowing AI Use in my LibrariesI’ve taken the decision to allow AI use for PRs to my libraries. I personally believe these tools can be a net add (with lots of straight jackets and caveats), but I also think we’ve reached a point where I can’t really be sure whether the incoming PR requests are from people using AI tooling to help them, or just free roaming OpenClaw instances that are masking their AI nature very well, and so it feels like I’d be firmly swimming against the current as a very part-time open source contributor to try and police this. To be an open and clear about my use of AI I’ve cut pre-ai releases for all my libraries so you can get access to the code from the point before I personally started to use AI tooling (I 100% cannot confirm whether any of the contributions from others to the libraries used AI or not, but I can say with certainty that I did not use AI before these points). The pre-ai tags are: utest.h ubench.h utf8.h json.h subprocess.h hashmap.h I’ve also added a disclaimer to the README.md of each of the repositories that states: AI Usage AI tool use is explicitly permitted in commits to this repository. There is a tagged release pre-ai that denotes the last release where AI tooling was not used. And each of the PRs authored by my pi.dev agent has the footer: 🧙 Conjured by AI via pi.dev using gpt-5.5 As does each commit the AI authored too.📝Neil Henning

Thursday, June 4, 2026

Polyhedron Processing Improvements in VTKPolyhedral cells (general convex or non-convex 3D cells with arbitrary face and vertex counts) appear throughout large-scale simulation, particularly in CFD. Some solvers produce them as the dual of a tetrahedral mesh; others use them as transition cells across refinement boundaries; still others build directly on face-based polyhedral connectivity as the native primitive. Several commercial and open source CFD codes have invested in face-based arbitrary polyhedral cells as a first-class primitive, and that investment runs all the way through the pre- and post-processing pipeline because handling polyhedra well at every stage is non-trivial.📝Kitware Inc
Choosing Values for Robust Tests@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 Radion Khait A test passes. Great! But does it really mean your code is working as expected? Not necessarily.Sometimes the values you choose in your tests can create a false sense of security, especially when dealing with default values. Consider this snippet of a simple map class and its corresponding unit test: Implementation Test void MyMap::insert(int key, int value) { // Oops! The map entry is default-initialized, // the second parameter is not used. internal_map_[key]; } TEST(MyMapTest, Insert) { MyMap my_map; my_map.insert(1, 0); // This passes! EXPECT_EQ(my_map.get(1), 0); } The test passes, but the insert method is broken! It never actually stores the value. The test only passes because the default value for an integer in the map (0) happens to match the value used in the test. When choosing test values, consider the following: Test with non-default values. Explicitly test with values different from the type's default (e.g., non-zero numbers, non-empty strings, enum values other than the one at index 0). This provides greater confidence that your code is actually using the provided input. TEST(MyMapTest, Insert) { MyMap my_map; my_map.insert(1, 5); // This test would fail and reveal the bug in // the implementation above: “Expected 5, got 0”. EXPECT_EQ(my_map.get(1), 5); } Test multiple inputs that cover different scenarios, where it is reasonable to do so. Consider empty/missing/null values, numerical boundaries, and special cases that trigger complex logic. Try to cover all distinct code/logic paths. Consider using fuzzing to more thoroughly cover the input domain. Use different values for each input. This guarantees the code under test doesn't accidentally reuse a single input or switch their order. Parameterized testing can also help test a large variety of inputs with minimal code duplication. TEST(MyMapTest, Insert) { // Use a different value for `key` and `value`. my_map.insert( /*key=*/ 1, / *value=*/ 2); EXPECT_EQ(my_map.at(1), 2); }📝Google Testing Blog

Wednesday, June 3, 2026

Tuesday, June 2, 2026

Monday, June 1, 2026

JetByte News: Thirty Years of JetByteToday marks the start of the 30th year of JetByte Limited. Where did the time go? We started as a ‘bum on seat’ contracting company so that Len could work for Credit Suisse Financial Products as a C++ developer back in 1997. This worked well, with interesting work, interesting people and lots of new skills to learn. When UK tax rules were changed we adjusted our working practices as the market changed and this turned out to be the best thing that could ever have happened.📝Rambling Comments - Len Holgate's blog

Sunday, May 31, 2026