Welcome to SwedenCpp

Latest blogs, videos, podcasts and releases in one stream

Monday, May 4, 2026

If this page is useful, please consider your support

Sunday, May 3, 2026

15 Different Ways to Filter Containers in Modern C++Do you know how many ways we can implement a filter function in C++? While the problem is relatively easy to understand - take a container, copy elements that match a predicate, and return a new container - it’s good to exercise with the C++ Standard Library and check a few ideas. We can also apply some Modern C++ techniques, including C++23. Let’s start! The article was written in 2021 and recently updated in late 2025 to include additional techniques from C++23. Additionally, the text is also republished on the ACCU website : ACCU Overload, 33: 15 Different Ways to Filter Containers in Modern C++ . The Problem Statement To be precise, by a filter I mean a function with the following interface: auto Filter(const Container& cont, UnaryPredicate p) {} It takes a container and a predicate, and creates an output container with elements (copies) that satisfy the predicate. We can use it like the following: const std :: vector std :: string > vec { "Hello" , "**txt" , "World" , "error" , "warning" , "C++" , "****" }; auto filtered = Filter ( vec , []( auto & elem ) { return ! elem . starts_with ( '*' ); }); // filtered should have "Hello", "World", "error", "warning", "C++" Writing such a function can be a good exercise with various options and algorithms in the Standard Library. What’s more, our function hides internal mechanisms like iterators, so it’s more like a range-based version. Let’s start with the first option: Good old Raw Loops While it’s good to avoid raw loops, they might help us to fully understand the problem. For our filtering problem, we can write the following code: // filter v1 template typename T , typename Pred > auto FilterRaw ( const std :: vector T >& vec , Pred p ) { std :: vector T > out ; for ( auto && elem : vec ) if ( p ( elem )) out . push_back ( elem ); return out ; } Simple yet very effective. Please note some nice features of this straightforward implementation. The code uses auto return type deduction, so there’s no need to write the explicit type (although it could be just std::vector ). It returns the output vector by value, but the compiler will leverage the copy elision (named return value optimization - NRVO), or move semantics at worse. Since we’re at raw loops, we can take a moment and appreciate range-based for loops that we get with C++11. Without this functionality, our code would look much worse: // filter v1 - old way template typename T , typename Pred > std :: vector T > FilterRawOld ( const std :: vector T >& vec , Pred p ) { std :: vector T > out ; for ( typename std :: vector T >:: const_iterator it = begin ( vec ); it != end ( vec ); ++ it ) if ( p ( * it )) out . push_back ( * it ); return out ; } And now let’s move to something better and see some of the existing std:: algorithms that might help us with the implementation. Filter by std::copy_if std::copy_if is probably the most natural choice. We can leverage back_inserter to push matched elements into the output vector. // filter v2 template typename T , typename Pred > auto FilterCopyIf ( const std :: vector T >& vec , Pred p ) { std :: vector T > out ; std :: copy_if ( begin ( vec ), end ( vec ), std :: back_inserter ( out ), p ); return out ; } std::remove_copy_if We can also do the reverse: // filter v3 template typename T , typename Pred > auto FilterRemoveCopyIf ( const std :: vector T >& vec , Pred p ) { std :: vector T > out ; std :: remove_copy_if ( begin ( vec ), end ( vec ), std :: back_inserter ( out ), std :: not_fn ( p )); return out ; } Depending on the requirements, we can also use remove_copy_if , which copies elements that do not satisfy the predicate. For our implementation, I had to add std::not_fn to reverse the predicate. One remark: std::not_fn has been available since C++17. The Famous Remove Erase Idiom One thing to remember: remove_if doesn’t remove elements; it only moves them to the end of the container. So we need to use erase to do the final work: // filter v4 template typename T , typename Pred > auto FilterRemoveErase ( const std :: vector T >& vec , Pred p ) { auto out = vec ; out . erase ( std :: remove_if ( begin ( out ), end ( out ), std :: not_fn ( p )), end ( out )); return out ; } Here’s a minor inconvenience. Because we don’t want to modify the input container, we had to copy it first. This might cause some extra processing and is less efficient than using back_inserter . Adding Some C++20 After seeing a few examples that can be implmented in C++11, we can leverage a convenient feature from C++20: erase_if : // filter v5 template typename T , typename Pred > auto FilterEraseIf ( const std :: vector T >& vec , Pred p ) { auto out = vec ; std :: erase_if ( out , std :: not_fn ( p )); return out ; } This function is superior to the remove/erase iodiom, as you can just use a single function. One minor thing, this approach copies all elements first. So it might be slower than the approach with copy_if . Adding Some C++20 Ranges C++20 also brought us powerful ranges and range algorithms, and we can use them as follows: // filter v6 template typename T , typename Pred > auto FilterRangesCopyIf ( const std :: vector T >& vec , Pred p ) { std :: vector T > out ; std :: ranges :: copy_if ( vec , std :: back_inserter ( out ), p ); return out ; } The code is super simple, and we might even say that our Filter function has no point here, since the Ranges interface is so easy to use in code directly. Making it More Generic So far, I showed you code that operates on std::vector . But how about other containers? Let’s try and make our Filter function more generic. This is easy with std::erase_if , which has overloads for many standard containers: // filter v7 template typename TCont , typename Pred > auto FilterEraseIfGen ( const TCont & cont , Pred p ) { auto out = cont ; std :: erase_if ( out , std :: not_fn ( p )); return out ; } And another version for ranges. // filter v8 template typename TCont , typename Pred > auto FilterRangesCopyIfGen ( const TCont & vec , Pred p ) { TCont out ; std :: ranges :: copy_if ( vec , std :: back_inserter ( out ), p ); return out ; } Right now, it can work with other containers, not only with std::vector : std :: set std :: string > mySet { "Hello" , "**txt" , "World" , "error" , "warning" , "C++" , "****" }; auto filtered = FilterEraseIfGen ( mySet , []( auto & elem ) { return ! elem . starts_with ( '*' ); }); On the other hand, if you prefer not to copy all elements upfront, we might need more work. Generic “copy_if” Approach The main problem is that we cannot use back_inserter on associative containers, or on containers that don’t support the push_back() member function. In that case, we can fall back to the std::inserter adapter. That’s why a possible solution is to detect if a given container supports push_back : // filter v9 template typename T , typename = void > struct has_push_back : std :: false_type {}; template typename T > struct has_push_back T , std :: void_t decltype ( std :: declval T > (). push_back ( std :: declval typename T :: value_type > ())) > > : std :: true_type {}; template typename TCont , typename Pred > auto FilterCopyIfGen ( const TCont & cont , Pred p ) { TCont out ; if constexpr ( has_push_back TCont >:: value ) std :: copy_if ( begin ( cont ), end ( cont ), std :: back_inserter ( out ), p ); else std :: copy_if ( begin ( cont ), end ( cont ), std :: inserter ( out , out . begin ()), p ); return out ; } Above, I used a technique available up to C++17 with void_t and SFINAE; read more here: How To Detect Function Overloads in C++17, std::from_chars Example - C++ Stories . But since C++20, we can leverage concepts and make the code much more straightforward.: template typename T > concept has_push_back = requires ( T container , typename T :: value_type v ) { container . push_back ( v ); }; And see more in Simplify Code with if constexpr and Concepts in C++17/C++20 - C++ Stories . More C++20 Concepts We can add more concepts and restrict other template parameters. For example, if I write: auto filtered = FilterCopyIf ( vec , []( auto & elem , int a ) { return ! elem . starts_with ( '*' ); }); In the above code I tried to use two arguments for the unary predicate. In Visual Studio I’m getting the following error message: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29333\include\algorithm(1713,13): error C2672: 'operator __surrogate_func': no matching overloaded function found 1> C:\Users\Admin\Documents\GitHub\articles\filterElements\filters.cpp(38): message : see reference to function template instantiation '_OutIt std::copy_if >>,std::back_insert_iterator >>,Pred>(_InIt,_InIt,_OutIt,_Pr)' being compiled 1> with Not very helpful… but then after a few lines, we have some clear reason: error C2780: 'auto main:: ::operator ()(_T1 &,int) const': expects 2 arguments - 1 provided We can experiment with concepts and restrict our predicate to be std::predicate , an existing concept from the Standard Library. In our case, we need a function that takes one argument and then returns a type convertible to bool . // filter v10 template typename T , std :: predicate const T &> Pred > // auto FilterCopyIfConcepts ( const std :: vector T >& vec , Pred p ) { std :: vector T > out ; std :: copy_if ( begin ( vec ), end ( vec ), std :: back_inserter ( out ), p ); return out ; } And then the problematic code: auto filtered = FilterCopyIfConcepts ( vec , []( auto & elem , int a ) { return ! elem . starts_with ( '*' ); }); This results in the following message: 1> filters.cpp(143,19): error C2672: 'FilterCopyIfConcepts': no matching overloaded function found 1> filters.cpp(143,101): error C7602: 'FilterCopyIfConcepts': the associated constraints are not satisfied It’s better, as we have messages about our top-level function rather than internals, but it would be great to see why and which constraint wasn’t satisfied. Making it Parallel? Since C++17, we also have parallel algorithms, so why not add them to our list? As it appears the parallel std::copy_if is not supported in Visual Studio, this problem is a bit more complicated. We’ll leave this topic for now and try to solve it next time. For completeness, we can write the following naive code: // filter v11 std :: mutex mut ; std :: for_each ( std :: execution :: par , begin ( vec ), end ( vec ), [ & out , & mut , p ]( auto && elem ) { if ( p ( elem )) { std :: unique_lock lock ( mut ); out . push_back ( elem ); } }); This is, of course, a naive version, and will make the process serialized. The topic is quite advanced, so please have a look at my other text and experiment ( filter v12 ): Implementing Parallel copy_If in C++ - C++ Stories . Direct filter support with ranges::filter_view , C++23 In C++23, we got std::ranges::filter_view and std::views::filter . So the code is much simpler now: // filter v13 template typename T , std :: predicate const T &> Pred > auto FilterRangesFilter ( const std :: vector T >& vec , Pred p ) { std :: vector T > out ; for ( const auto & elem : vec | std :: views :: filter ( p )) out . push_back ( elem ); return out ; } Adding ranges::to , C++23 What’s more, we can use ranges::to to automatically create a container. // filter v14 template typename T , std :: predicate const T &> Pred > auto FilterRangesFilterTo ( const std :: vector T >& vec , Pred p ) { return vec | std :: views :: filter ( p ) | std :: ranges :: to std :: vector > (); } Additionally, ranges::to works with any container type and determines an appropriate way to populate it. So it works with more than just std::vector : Here’s an example: template typename Cont , std :: predicate const typename C :: value_type &> Pred > auto FilterRangesFilterTo ( const Cont & vec , Pred p ) { return vec | std :: views :: filter ( p ) | std :: ranges :: to Cont > (); } C++23: Lazy Filtering with std::generator All previous versions of Filter in this article return a materialised container - a std::vector , std::set , or something similar. That’s often what we want, but sometimes it’s more efficient to: avoid allocating a separate container, process elements on the fly (e.g. streaming input, large ranges), or combine filtering with another lazy pipeline. C++23 adds std::generator , a coroutine-based type that models a range. We can use it to express a lazy filter : template typename T , std :: predicate const T &> Pred > std :: generator const T &> FilterLazy ( const std :: vector T >& vec , Pred p ) { for ( const auto & elem : vec ) { if ( p ( elem )) co_yield elem ; } } Usage is straightforward: std :: vector std :: string > vec { "Hello" , "**txt" , "World" , "error" , "warning" , "C++" , "****" }; auto gen = FilterLazy ( vec , []( const auto & s ) { return ! s . starts_with ( '*' ); }); // Elements are produced lazily, on demand: for ( const auto & s : gen ) { std :: cout s '\n' ; } A few essential properties of this approach: Lazy evaluation - elements are filtered only when you iterate the generator. No intermediate container - no extra allocation by default. Summary In this article, I’ve shown at least 15 possible ways to filter elements from various containers. We started from code that worked on std::vector , and you’ve also seen multiple ways to make it more generic and applicable to other container types. For example, we used std::erase_if from C++20, concepts, and even a custom type trait. We also used the “holy grail” of C++23 with ranges::filter and ranges::to . See my code, with all the examples, on this repository: https://github.com/fenbf/articles/blob/master/filterElements/filters.cpp📝C++ Stories

Saturday, May 2, 2026

Every float on one pagevitaut.net https://vitaut.net/posts/2026/every-float/ - In my previous post about Żmij , a high-performance binary-to-decimal floating-point conversion library, I drew a small diagram of a rounding interval around a single floating-point value. That worked well enough for the local picture, but it doesn’t say much about the global one. Where do the irregular intervals at powers of two come from? What does the subnormal range actually look like? And how do the binades (the $[2^e, 2^{e+1})$ slices of the real line on which all FP numbers share an exponent) fit together? So I tried to draw that instead: the entire set of representable numbers, laid out so the interesting structure is visible at a glance. A small format that is actually used To draw all the floats you really need a small format. Luckily small formats have recently escaped the textbook: 8-bit floating-point formats are now used in production for AI training and inference. The one we will look at here is E4M3 : 1 sign bit, 4 exponent bits, 3 significand bits, bias 7, with subnormals and a single NaN slot. It is specified in FP8 Formats for Deep Learning by NVIDIA, Arm and Intel, three companies that famously agree on very little, and is supported in hardware by GPUs such as the H100, H200 and B200, where it is the workhorse format for low-precision inference. E4M3 has only 256 encodings, so we can comfortably show every value at once and still have room to think. The usual picture is a single line The traditional way to visualize floating-point numbers is to put them on a real number line. For E4M3 the result is accurate but not very useful: most of the action is squeezed near zero, huge gaps open up near the maximum, and there is nothing on the page that tells you why the spacing changes the way it does. (You can see for yourself in the linear number line panel at the bottom of the embedded explorer further down.) The structure that makes floating-point floating-point, the partition into binades, is exactly the thing the linear axis hides. Zooming in helps a bit, but it doesn’t scale: at any zoom level you only ever see a slice of one or two binades, and the relationship between the binary representation and the decimal positions is still mostly invisible. A 2-D picture, suggested by an LLM After some back and forth with an LLM, a much better idea came up: forget the linear axis, just plot every value by its exponent. The first sketch was crude but got the point across, which was more than I had any right to expect from a vibe-coding session: Log₂ scale (this is the "real" structure) E = -9 • • • • • • • (subnormals) E = -6 • • • • • • • • E = -5 • • • • • • • • E = -4 • • • • • • • • E = -3 • • • • • • • • E = -2 • • • • • • • • E = -1 • • • • • • • • E = 0 • • • • • • • • E = 1 • • • • • • • • E = 2 • • • • • • • • E = 3 • • • • • • • • E = 4 • • • • • • • • E = 5 • • • • • • • • E = 6 • • • • • • • • E = 7 • • • • • • • • 👉 Every exponent bucket has exactly 8 evenly spaced values 👉 That's why FP behaves like a logarithmic number system The reason this works is that every finite floating-point value can be written as $c \cdot 2^{e_2}$ with $c$ an integer in a small range. For E4M3 normals $c \in \{8, \ldots, 15\}$ and $e_2 = E - 10$; for subnormals $c \in \{1, \ldots, 7\}$ and $e_2 = -9$. So every value sits at integer coordinates $(c, e_2)$: the rows are binades, the columns are integer significands, and within each row the dots are linearly spaced. The mysterious “logarithmic spacing” of floating-point numbers is just what you see when you stack these linear rows and look at them from the side. Vibe-coded into something usable A few more iterations and the sketch turned into the interactive explorer below ( standalone page , source ). Click any dot to inspect the value, toggle subnormals and NaN, or scrub through the encoding directly: Two axes, two scales: the binary exponent $e_2$ runs down the left, and the matching decimal exponent $e_{10} = \lfloor e_2 \log_{10} 2 \rfloor$ down the right. A few things to look at: The horizontal line through each row is the binade, extended by half a cell on each side. Those half-cells are exactly the rounding interval : real numbers between them round back to the dot in the middle (modulo rounding-mode tie-breaks I’m glossing over). Crossing each row are vertical decimal ticks at two scales: minor every $10^{e_{10}}$, major every $10^{e_{10}+1}$. They are the only two decimal grids that matter in that binade. Anything coarser misses the rounding interval, anything finer just adds digits. So shortest-decimal conversion is one row’s worth of work: pick a dot, find the coarsest tick that lands inside its rounding interval. Reading the shortest decimal by hand Let’s pick a value and walk through it. Set the encoding to 51 in the explorer (or click the dot at row $e_2 = -4$, column $c = 11$). The bits are 0 0110 011 , i.e. $E = 6$, $M = 3$, so $$ v = (8 + 3) \cdot 2^{6 - 10} = 11 \cdot 2^{-4} = 0.6875. $$ Its row is $e_2 = -4$, with $e_{10} = \lfloor -4 \log_{10} 2 \rfloor = -2$. So on this row: minor ticks are at multiples of $10^{-2} = 0.01$, major ticks are at multiples of $10^{-1} = 0.1$. The dot’s neighbors in the binade are at $10 \cdot 2^{-4} = 0.625$ on the left and $12 \cdot 2^{-4} = 0.75$ on the right. The half-cells around the dot therefore span $(0.65625, 0.71875)$, the rounding interval. Now eyeball the ticks in that interval: The major tick at $0.7$ sits right inside it. (Several minor ticks $0.66, 0.67, \ldots, 0.71$ are also inside, but we don’t care: the major tick already gives the shortest answer.) Therefore the shortest decimal that round-trips through E4M3 to $0.6875$ is simply 0.7 . No tables, no big-integer arithmetic, just one dot and the ticks on its row. This is exactly what Schubfach (and Dragonbox, and Żmij) compute for double , just at a much larger scale and with a lot more arithmetic to keep track of: pick the coarsest decimal grid whose spacing still fits inside the rounding interval, then round the value to that grid. Where the special cases go Subnormals turn out to be just the bottom row $e_2 = -9$, with the column index running $1\ldots 7$ instead of $8\ldots 15$ and the leftmost half-cell extending a little further than usual. The irregular rounding intervals at powers of two show up at the leftmost normal column ($c = 8$ in every row except the bottom), where the left half-cell is shorter than the right because the predecessor sits in the binade below and is only half a ULP away. Even the e10 vs e10 + 1 decision in Schubfach has an obvious reading: “does the major tick fit inside the interval, or do we have to fall back to minor ticks?”. The full explorer is a single HTML/JS/SVG file with no build step; if you want to fork it, adapt it to a different format ( E5M2 ? bfloat16 ? Whatever your hardware vendor invents next quarter?), or just read how it’s wired together, the source is in the website’s repo . Happy floatspotting! window.MathJax = { tex: { inlineMath: [['$', '$'], ['\\(', '\\)']], displayMath: [['$$', '$$'], ['\\[', '\\]']] }, svg: { fontCache: 'global' } }; - https://vitaut.net/posts/2026/every-float/ -📝vitaut.net

Friday, May 1, 2026

Thursday, April 30, 2026

_Adventure:_ Is there light in the cobble crawl?The original _Colossal Cave Adventure_ consists basically of a Fortran source file and a textual data file. These files would often travel from one installation to another via paper printouts: printed out at one site, typed in by hand at another. The lines of WOOD0350's Fortran source (intentionally or not) never exceed 80 columns regardless of your tab stop. But the data file fits within 80 columns only with a tab stop of four. With an eight-space tab stop, four lines of the data file exceed 80 columns:📝Arthur O’Dwyer

Wednesday, April 29, 2026

My 7-min “lightning talk” is online: Why C++ is growing, and why C++26 will likely be adopted quicklyAt the London C++ meetup last month, I participated on a panel where each panelist gave a short introductory presentation. My 7-minute intro (aka “lightning talk”) just got posted — you can view it here. The one-sentence blurb: “C++ is accelerating, and C++26 is built for what developers need now.” Also check out the longer … Continue reading My 7-min “lightning talk” is online: Why C++ is growing, and why C++26 will likely be adopted quickly →📝Sutter’s Mill
Figma to Qt 1.0 Is Here: The Most Reliable Way to Bring Your Design From Figma to DeviceWhen a perfectly crafted design leaves Figma and enters a development pipeline, things often get compromised. Spacing shifts, colors change, and details deviate through multiple layers of interpretation and unexpected limitations. You will see timelines lagging, design becoming unclear, and user experience losing priority. Figma to Qt is built to ensure your GUI designs get from Figma to device . Version 1.0 is now available for free download in the Figma Community .📝Qt Blog
One Map Key, One Lookup@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 Roman Govsheev Can you spot the wasted CPU cycles in the map usage? if employee_id in employees: mail_to(employees[employee_id].email_address) The redundant lookup caused the waste by performing a check ( in ) and a fetch ( [] ) as two separate operations when one is sufficient. Every lookup involves a cost —whether it's computing a hash and scanning buckets or performing an O (log n ) traversal. These costs add up quickly. But avoiding them isn’t just “premature optimization”—it’s about writing cleaner, more robust code that stays efficient at scale and prevents potential race conditions. Instead of paying this cost twice, perform the lookup once and reuse the result: if ( employee := employees.get(employee_id)) is not None: mail_to( employee .email_address) Assigning the search result to a variable avoids a second lookup. This efficiency is native to Go via the “comma ok” idiom ( val, ok := map[key] ) and C++ using map.find(key) , both handling retrieval and existence in a single pass. The same inefficiency applies when counting or initializing default. Stop checking for presence; instead, use idioms that handle missing keys automatically at the container level : The redundant way The efficient way If key not in counts: counts[key] = 1 else: counts[key] += 1 counts = defaultdict(int) # Initializes 0 automatically # ... other logic ... counts[key] += 1 Here are some details depending on which language you use: C++: operator[] returns a reference to the value—automatically inserting a default (like 0) if the key is missing—allowing the increment to happen in place. Java: Use map.computeIfAbsent() to perform retrieval and updates in a single call. This is more concise and, on concurrent collections, has the potential to be thread-safe—preventing the “check-then-act” race conditions common with separate contains and put calls. Python: Use collections.defaultdict to handle defaults at the container level, which pushes the logic into optimized C code for better performance and robustness. Note that the += operation (shown later in the above code sample) still involves both a read and a write operation. Go: Use val, ok := map[key] to handle retrieval and existence in one memory access.📝Google Testing Blog

Tuesday, April 28, 2026

_Adventure:_ Walking on the ceilingOn 2012-12-01 I wrote to Don Woods (in a postscript to a production update on [_Colossal Cave: The Board Game_](https://boardgamegeek.com/boardgame/121751/colossal-cave-the-board-game)): > By the way, I just noticed last week that in "Adventure", in the Hall > of the Mountain King, the directions NORTH and LEFT are synonyms, as > are SOUTH and RIGHT... as are WEST and FORWARD! West being forward > makes sense, if the Hall of Mists is back to the east; but for the > rest I suppose the adventurer must be walking on the ceiling. :) This > little mixup is present all the way back to > [Crowther's code](https://github.com/Quuxplusone/Advent/blob/master/CROW0005/advdat.77-03-11#L249-L253). > I just thought it was funny that nobody had commented on it before, as > far as I know.📝Arthur O’Dwyer