Welcome to SwedenCpp

Latest blogs, videos, podcasts and releases in one stream

Friday, June 5, 2026

If this page is useful, please consider donating a coffee

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

Saturday, May 30, 2026