Use the following template (C++20) for efficient and near-optimal binary search (in terms of number of queries) on floating point numbers.

template <std::size_t N_BITS>
using int_least_t = std::conditional_t<
    N_BITS <= 8, std::uint8_t,
    std::conditional_t<
        N_BITS <= 16, std::uint16_t,
        std::conditional_t<
            N_BITS <= 32, std::uint32_t,
            std::conditional_t<
                N_BITS <= 64, std::uint64_t,
                std::conditional_t<N_BITS <= 128, __uint128_t, void>>>>>;

// this should work for float and doubles, but for long doubles, std::bit_cast will fail on most systems due to being 80 bits wide.
// to handle this, consider using doubles instead or std::bit_cast the long double to an 80-bit bitset and convert it to a 128 bit integer using to_ullong.

/*
   * returns first x in [a, b] such that predicate(x) is false, conditioned on
   * logical_predicate(a) && !logical_predicate(b) && logical_predicate(-inf) &&
   * !logical_predicate(inf)

   * here logical_predicate is the mathematical value of the predicate, not the
   * machine value of the predicate

   * it is guaranteed that non-nan, non-inf inputs are passed into the predicate

   * if NaNs or infinities are passed to this function as argument, then the
   * inputs to the predicate will start from smallest/largest representable
   * floating point numbers of the input type - this can be a source of errors
   * if you multiply the input by something > 1 for example

   * strictly speaking, the predicate should also be perfectly monotonic, but if
   * it gives out-of-order booleans in some small range [a, a + eps] (and the
   * correct order elsewhere), then the answer will be somewhere in between

   * the same holds for how denormals are handled by this code

   */
//
template <bool check_infinities = false,
          bool distinguish_plus_minus_zero = false,
          bool deal_with_nans_and_infs = false, std::floating_point T>
T partition_point_fp(T a, T b, auto&& predicate) {
    static constexpr std::size_t T_WIDTH = sizeof(T) * CHAR_BIT;
    using Int = int_least_t<T_WIDTH>;
    static constexpr auto is_negative = [](T x) {
        return static_cast<bool>((std::bit_cast<Int>(x) >> (T_WIDTH - 1)) & 1);
    };
    if constexpr (distinguish_plus_minus_zero) {
        if (a == T(0.0) && b == T(0.0) && is_negative(a) && !is_negative(b)) {
            if (!predicate(-T(0.0))) {
                return -T(0.0);
            } else {
                // predicate(0.0) is guaranteed to be true because b = 0.0
                return T(0.0);
            }
        }
    }

    if (a >= b) return NAN;

    if constexpr (deal_with_nans_and_infs) {
        // get rid of NaNs as soon as possible
        if (std::isnan(a)) a = -std::numeric_limits<T>::infinity();
        if (std::isnan(b)) b = std::numeric_limits<T>::infinity();

        // deal with infinities
        if (a == -std::numeric_limits<T>::infinity()) {
            if constexpr (check_infinities) {
                if (predicate(-std::numeric_limits<T>::max())) {
                    a = -std::numeric_limits<T>::max();
                } else {
                    return -std::numeric_limits<T>::max();
                }
            } else {
                a = -std::numeric_limits<T>::max();
            }
        }
        if (b == std::numeric_limits<T>::infinity()) {
            if constexpr (check_infinities) {
                if (!predicate(std::numeric_limits<T>::max())) {
                    b = std::numeric_limits<T>::max();
                } else {
                    return std::numeric_limits<T>::infinity();
                }
            } else {
                b = std::numeric_limits<T>::max();
            }
        }
    }

    // now a and b are both finite - deal with differently signed a and b
    if (is_negative(a) && !is_negative(b)) {
        // check 0 once
        if constexpr (distinguish_plus_minus_zero) {
            if (!predicate(-T(0.0))) {
                b = -T(0.0);
            } else if (predicate(T(0.0))) {
                a = T(0.0);
            } else {
                return T(0.0);
            }
        } else {
            if (!predicate(T(0.0))) {
                b = -T(0.0);
            } else {
                a = T(0.0);
            }
        }
    }

    // in the case a and b are both 0 after the above check, return 0
    if (a == b) return T(0.0);

    // start actual binary search
    auto get_int = [](T x) { return std::bit_cast<Int, T>(x); };
    auto get_float = [](Int x) { return std::bit_cast<T, Int>(x); };
    if (b > 0) {
        while (get_int(a) + 1 < get_int(b)) {
            auto m = std::midpoint(get_int(a), get_int(b));
            if (predicate(get_float(m))) {
                a = get_float(m);
            } else {
                b = get_float(m);
            }
        }
    } else {
        while (get_int(-b) + 1 < get_int(-a)) {
            auto m = std::midpoint(get_int(-b), get_int(-a));
            if (predicate(-get_float(m))) {
                a = -get_float(m);
            } else {
                b = -get_float(m);
            }
        }
    }
    return b;
}

It is also possible to extend this to breaking early when a custom closeness predicate is true (for example, min(absolute error, relative error) < 1e-9 and so on), but for the sake of simplicity, this template does not do so.

Introduction

It is well known that writing the condition for continuation of the binary search as anything like while (r - l > 1) or while (l < r) is bug-prone on floating point integers, so people tend to write a binary search by fixing the number of iterations. However, this is usually not the best method --- you need $O(\log L)$ iterations where $L$ is the length of the range, and the range of floating point numbers is very large.

So, I came up with a way to binary search on (IEEE754, i.e., practically all implementations of) floating point numbers that takes bit_width(floating_type) + O(1) calls to the predicate for binary search. I am pretty sure that this method has been explored before (feel free to drop references in the comments if you find them). Regardless of whether this is a novel algorithm or not, I wanted to share this since it teaches you a lot about floating points, and it also has the following advantages:

• No need to hard-code the number of iterations.
• It avoids issues that you get in other implementations (for example, using sqrt, you end up with a ton of cases with 0, negatives and so on).
• It is efficient (sqrt is expensive, and so is dealing with a lot of cases).

Arriving at the algorithm

I started out by thinking about this: floating point numbers have a very large range. Can we do better than $O(\log L)$ where $L$ is the length of the range? Recall that floating point numbers also have a fixed width that is much smaller than the log of the range they represent, and between two consecutive representable floating point numbers, it is their ratio that is nicely bounded (ignoring the boundary of 0 and inf and nans) instead of their difference. Now since it is well-known that for getting to a certain relative-error, it is optimal to use $\sqrt{lr}$ instead of $\frac{l + r}{2}$ in binary search.

So the first idea that comes to mind is to use sqrt instead of midpoint in the usual binary search. However, it has a lot of issues --- for example, if $l = 0$, then you never progress in the binary search (this is fixable by doing a midpoint search on 0 to 1 and sqrt search on 1 to $r$). One more issue is how to deal with negatives (this is again doable by splitting the input range into multiple ranges where sqrt works) and with overflows/underflows. And the main issue with this approach is that sqrt is expensive --- if you are doing a problem where the predicate is pretty fast and you need to do a lot of binary searches, most of your computation time would be due to sqrt.

Inspired by these, we decide to try to approximate sqrt in a way that preserves monotonicity. Here comes the main point --- note that the IEEE754 implementation of floating point numbers separates the mantissa from the exponent, and the exponent part of $\sqrt{lr}$ is roughly the mean of that of $l$ and $r$. Since these are the top few bits (excluding the sign bit), we can just do the following (for positive floating point numbers at least): read the floating point representation as an integer (this can be done in a type-safe manner by using std::bit_cast), take the midpoint of these integers, and convert it back to a floating point number. This clearly preserves monotonicity --- this can be verified easily by hand. Note that this same thing works for when both range endpoints are negative numbers too --- for this we simply invert the sign bit. The case where both are of opposite signs is also simple (if you disregard the fact that +0 and -0 are equal but have distinct representations and reciprocals) --- check the predicate on $0$ (both the zeroes if it matters for your predicate).

Now if we want to do some more handling (infinities, NaNs, denormals), we can do it as we wish. In the implementation in the TL;DR above, we decide to replace NaNs with the infinity in the correct direction, and since there can be many infinities, we try to bring down the range endpoint to the largest representable floating point instead.

Analysis

In all, there are at most $w + O(1)$ calls to the predicate, where $w$ is the length of the complement of the longest common prefix of the floating point representations of endpoints.

This implementation is also robust to predicates which are noisy near the boundary (i.e., near the boundary, there is a small range where the true values of the predicate can come after the false values) --- in this case the algorithm returns something in this range near the boundary.

Note that we did not need to hardcode the number of iterations, nor did we require some carefully-written predicate for loop termination.

Also, since std::bit_cast is practically free compared to std::sqrt, it is much faster in cases where you need to do a lot of binary searches.

As a usage example, this submission uses the usual binary search with fixed number of iterations, and this submission uses the template above.

Some problems

The following are some problems that use binary search on floating points, and should be solvable using this template. If you encounter any bugs in the template while solving these problems, do let me know in the comments below. Thanks to jeroenodb and PurpleCrayon for problem suggestions.

@online{floating-point-binsearch-2024,
  author    = {nor},
  title     = {Convenient and near-optimal binary search on floating point numbers},
  year      = {2024},
  month     = {03},
  day       = {05},
  url       = {https://nor-blog.pages.dev/posts/2024-03-05-floating-point-binsearch},
}

Here's what you will find implementations for in this post:

• Generalized hashing (for tuple types, sequence types and basic types)
• Convenient aliases for policy based data structures
• Wrappers for recursive (or otherwise) lambdas that automatically do caching (memoization) for you.

Jump to the Usage section if you only care about the template, though I would strongly recommend reading the rest of the post too since it has a lot of cool/useful things in my opinion.

Motivation

There are two major ways in which dynamic programming is implemented --- recursive and iterative.

Recursive DP has the following advantages:

• It is (arguably) the cleaner way for beginners, and is often easier to reason about mathematically.
• It is needed in problems where you want to only traverse the states required for computing your answer and no others.

However, people switch to iterative DP as their default DP implementation, because of the following reasons:

• Recursive DP is sometimes slower compared to iterative DP when they compute the same number of states.
• It is much easier to do push DP iteratively.
• Recursive DP takes more boilerplate to write (something along the lines of "if computed already, return the stored value; otherwise, do the following").

The template talked about in the above comment aims to tackle the third point by reducing boilerplate code --- it does this by automatically managing memoization for you.

Implementation

In Python, you have nice things called decorators. For example, the functools.cache decorator is precisely what we would use for such a purpose:

from functools import cache
@cache
def factorial(n):
    return n * factorial(n - 1) if n else 1

If you call factorial(10), then the internal cache will be populated with the results of all the recursive calls that were required to compute factorial(10). As a result, you can call factorial(5) and it will just look it up in the internal cache and return the value to you without calling the function body.

So I thought, why not try to do the same thing in C++?

Let's get a couple of things out of the way first:

• Note that Python dictionaries support heterogeneous types, but you can't do this without type erasure (in C++ or otherwise). So I decided to keep types homogeneous, i.e., the internal cache has keys of the same type. This was done to avoid performance hits, and it made sense because in competitive programming, people don't really use DP states that have heterogeneous types.
• Functions in C++ can take arguments by value or by reference. But in Python, arguments are taken by name. For the purposes of DP, since it doesn't really make sense to make states mutable, we decide that we will pass everything by value (there are a few pointers in the Caveats section if you are worried about performance implications due to copying a lot, but these are often not important since DP states tend to be integers/small types most of the time).

So let's start out by trying to design it.

We need the following two parts:

1. A wrapper around a function that is able to store calls to the function and their results.
2. Generalized hashing, to be able to store results.

Let's solve the first problem first. Hashing arbitrary structs in C++ is quite hard (not impossible, though). But what you can always do (for structs whose intent is to just store elements) is to supply a function that makes them tuples (i.e., provide a type conversion operator). For our problem, we identify the most important types that we will ever need to hash:

• Native integral types (including characters)
• Sequence types (vectors, sets, maps)
• Tuple types (tuples, pairs)

The last two are uniformly recursive on their inputs (except for vector<bool>, but our implementation doesn't need to treat it separately), so we can do recursive metaprogramming to be able to hash such types.

All in all, we need a hashing function that hashes the "base case" and a hash combination function that aggregates over the sequence/tuple types.

The implementation becomes something like this:

namespace hashing {
    using i64 = std::int64_t;
    using u64 = std::uint64_t;
    static const u64 FIXED_RANDOM = std::chrono::steady_clock::now().time_since_epoch().count();

#if USE_AES
    std::mt19937 rd(FIXED_RANDOM);
    const __m128i KEY1{(i64)rd(), (i64)rd()};
    const __m128i KEY2{(i64)rd(), (i64)rd()};
#endif

    template <class T, class D = void>
    struct custom_hash {};

    // https://www.boost.org/doc/libs/1_55_0/doc/html/hash/combine.html
    template <class T>
    inline void hash_combine(u64& seed, const T& v) {
        custom_hash<T> hasher;
        seed ^= hasher(v) + 0x9e3779b97f4a7c15 + (seed << 12) + (seed >> 4);
    };

    // http://xorshift.di.unimi.it/splitmix64.c
    template <class T>
    struct custom_hash<T, typename std::enable_if<std::is_integral<T>::value>::type> {
        u64 operator()(T _x) const {
            u64 x = _x;
#if USE_AES
            // implementation defined till C++17, defined from C++20
            __m128i m{i64(u64(x) * 0xbf58476d1ce4e5b9u64), (i64)FIXED_RANDOM};
            __m128i y = _mm_aesenc_si128(m, KEY1);
            __m128i z = _mm_aesenc_si128(y, KEY2);
            return z[0];
#else
            x += 0x9e3779b97f4a7c15 + FIXED_RANDOM;
            x = (x ^ (x >> 30)) * 0xbf58476d1ce4e5b9;
            x = (x ^ (x >> 27)) * 0x94d049bb133111eb;
            return x ^ (x >> 31);
#endif
        }
    };

    template <class T>
    struct custom_hash<T, std::void_t<decltype(std::begin(std::declval<T>()))>> {
        u64 operator()(const T& a) const {
            u64 value = FIXED_RANDOM;
            for (auto& x : a) hash_combine(value, x);
            return value;
        }
    };

    template <class... T>
    struct custom_hash<std::tuple<T...>> {
        u64 operator()(const std::tuple<T...>& a) const {
            u64 value = FIXED_RANDOM;
            std::apply([&value](T const&... args) { (hash_combine(value, args), ...); }, a);
            return value;
        }
    };

    template <class T, class U>
    struct custom_hash<std::pair<T, U>> {
        u64 operator()(const std::pair<T, U>& a) const {
            u64 value = FIXED_RANDOM;
            hash_combine(value, a.first);
            hash_combine(value, a.second);
            return value;
        }
    };

};  // namespace hashing

Now for the hash table, we could just use std::unordered_map. However, it often turns out to be slower than the GNU policy based data structure gp_hash_table, so we also define some aliases that are helpful.

#include "ext/pb_ds/assoc_container.hpp"
#include "ext/pb_ds/tree_policy.hpp"

namespace pbds {
    using namespace __gnu_pbds;
#ifdef PB_DS_ASSOC_CNTNR_HPP
    template <class Key, class Value, class Hash>
    using unordered_map = gp_hash_table<Key, Value, Hash, std::equal_to<Key>, direct_mask_range_hashing<>, linear_probe_fn<>,
                                        hash_standard_resize_policy<hash_exponential_size_policy<>, hash_load_check_resize_trigger<>, true>>;
    template <class Key, class Hash>
    using unordered_set = pbds::unordered_map<Key, null_type, Hash>;
#endif
#ifdef PB_DS_TREE_POLICY_HPP
    template <typename T>
    using ordered_set = tree<T, null_type, std::less<T>, rb_tree_tag, tree_order_statistics_node_update>;
    template <typename T>
    using ordered_multiset = tree<T, null_type, std::less_equal<T>, rb_tree_tag, tree_order_statistics_node_update>;
    template <class Key, class Value, class Compare = std::less<Key>>
    using ordered_map = tree<Key, Value, Compare, rb_tree_tag, tree_order_statistics_node_update>;
#endif
}  // namespace pbds

Now the only thing that remains is to actually decide the design of the wrapper.

We make the following choices:

• As mentioned above, we won't support reference semantics for now.
• We can choose to use either lambdas or plain old functions. Functions can't "capture" any state, and thus you need to make things global for using them with functions (or pass them as references, which we already disallowed). Hence, we will support lambdas and not functions for the sake of generality.
• We will choose to implement the wrapper as a struct that stores the lambda as well as the cache (hash table mapping tuples of input arguments to return values) inside it, and has its own operator() (call operator) that looks into the cache and returns the answer if found, else calls the lambda recursively and updates the cache (both recursively and for the current call).

This is done as follows:

template <typename Signature, typename Lambda>
struct Cache;

template <typename ReturnType, typename... Args, typename Lambda>
struct Cache<ReturnType(Args...), Lambda> {
    template <typename... DummyArgs>
    ReturnType operator()(DummyArgs&&... args) {
        auto tied_args = std::tie(args...);
        auto it = memo.find(tied_args);
        if (it == memo.end()) {
            auto&& ans = f(*this, std::forward<DummyArgs>(args)...);
            memo[tied_args] = ans;
            return ans;
        } else {
            return it->second;
        }
    }

    template <class _Lambda>
    Cache(std::tuple<>, _Lambda&& _f) : f(std::forward<_Lambda>(_f)) {}

    Lambda f;
    using TiedArgs = std::tuple<std::decay_t<Args>...>;
    pbds::unordered_map<TiedArgs, ReturnType, hashing::custom_hash<TiedArgs>> memo;
};

template <class Signature, class Lambda>
auto use_cache(Lambda&& f) {
    return Cache<Signature, Lambda>(std::tuple{}, std::forward<Lambda>(f));
}

Usage

The usage is very simple.

Here's the whole template for reference:

namespace hashing {
    using i64 = std::int64_t;
    using u64 = std::uint64_t;
    static const u64 FIXED_RANDOM = std::chrono::steady_clock::now().time_since_epoch().count();

#if USE_AES
    std::mt19937 rd(FIXED_RANDOM);
    const __m128i KEY1{(i64)rd(), (i64)rd()};
    const __m128i KEY2{(i64)rd(), (i64)rd()};
#endif

    template <class T, class D = void>
    struct custom_hash {};

    // https://www.boost.org/doc/libs/1_55_0/doc/html/hash/combine.html
    template <class T>
    inline void hash_combine(u64& seed, const T& v) {
        custom_hash<T> hasher;
        seed ^= hasher(v) + 0x9e3779b97f4a7c15 + (seed << 12) + (seed >> 4);
    };

    // http://xorshift.di.unimi.it/splitmix64.c
    template <class T>
    struct custom_hash<T, typename std::enable_if<std::is_integral<T>::value>::type> {
        u64 operator()(T _x) const {
            u64 x = _x;
#if USE_AES
            // implementation defined till C++17, defined from C++20
            __m128i m{i64(u64(x) * 0xbf58476d1ce4e5b9u64), (i64)FIXED_RANDOM};
            __m128i y = _mm_aesenc_si128(m, KEY1);
            __m128i z = _mm_aesenc_si128(y, KEY2);
            return z[0];
#else
            x += 0x9e3779b97f4a7c15 + FIXED_RANDOM;
            x = (x ^ (x >> 30)) * 0xbf58476d1ce4e5b9;
            x = (x ^ (x >> 27)) * 0x94d049bb133111eb;
            return x ^ (x >> 31);
#endif
        }
    };

    template <class T>
    struct custom_hash<T, std::void_t<decltype(std::begin(std::declval<T>()))>> {
        u64 operator()(const T& a) const {
            u64 value = FIXED_RANDOM;
            for (auto& x : a) hash_combine(value, x);
            return value;
        }
    };

    template <class... T>
    struct custom_hash<std::tuple<T...>> {
        u64 operator()(const std::tuple<T...>& a) const {
            u64 value = FIXED_RANDOM;
            std::apply([&value](T const&... args) { (hash_combine(value, args), ...); }, a);
            return value;
        }
    };

    template <class T, class U>
    struct custom_hash<std::pair<T, U>> {
        u64 operator()(const std::pair<T, U>& a) const {
            u64 value = FIXED_RANDOM;
            hash_combine(value, a.first);
            hash_combine(value, a.second);
            return value;
        }
    };

};  // namespace hashing

#include "ext/pb_ds/assoc_container.hpp"
#include "ext/pb_ds/tree_policy.hpp"

namespace pbds {
    using namespace __gnu_pbds;
#ifdef PB_DS_ASSOC_CNTNR_HPP
    template <class Key, class Value, class Hash>
    using unordered_map = gp_hash_table<Key, Value, Hash, std::equal_to<Key>, direct_mask_range_hashing<>, linear_probe_fn<>,
                                        hash_standard_resize_policy<hash_exponential_size_policy<>, hash_load_check_resize_trigger<>, true>>;
    template <class Key, class Hash>
    using unordered_set = pbds::unordered_map<Key, null_type, Hash>;
#endif
#ifdef PB_DS_TREE_POLICY_HPP
    template <typename T>
    using ordered_set = tree<T, null_type, std::less<T>, rb_tree_tag, tree_order_statistics_node_update>;
    template <typename T>
    using ordered_multiset = tree<T, null_type, std::less_equal<T>, rb_tree_tag, tree_order_statistics_node_update>;
    template <class Key, class Value, class Compare = std::less<Key>>
    using ordered_map = tree<Key, Value, Compare, rb_tree_tag, tree_order_statistics_node_update>;
#endif
}  // namespace pbds

template <typename Signature, typename Lambda>
struct Cache;

template <typename ReturnType, typename... Args, typename Lambda>
struct Cache<ReturnType(Args...), Lambda> {
    template <typename... DummyArgs>
    ReturnType operator()(DummyArgs&&... args) {
        auto tied_args = std::tie(args...);
        auto it = memo.find(tied_args);
        if (it == memo.end()) {
            auto&& ans = f(*this, std::forward<DummyArgs>(args)...);
            memo[tied_args] = ans;
            return ans;
        } else {
            return it->second;
        }
    }

    template <class _Lambda>
    Cache(std::tuple<>, _Lambda&& _f) : f(std::forward<_Lambda>(_f)) {}

    Lambda f;
    using TiedArgs = std::tuple<std::decay_t<Args>...>;
    pbds::unordered_map<TiedArgs, ReturnType, hashing::custom_hash<TiedArgs>> memo;
};

template <class Signature, class Lambda>
auto use_cache(Lambda&& f) {
    return Cache<Signature, Lambda>(std::tuple{}, std::forward<Lambda>(f));
}

Let's first try to replicate the python example from above:

auto factorial = use_cache<int(int)>([](auto&& self, int n) -> int {
    if (n) return n * self(n - 1);
    else return 1;
});
std::cout << factorial(10) << '\n';

You can do more complicated things with this template too. Let's say you want to have a recursive function that takes a char and pair<int, string> as a DP state, and stores a bool. It also requires values of some array you have taken as input, so you need to capture it as well.

You write it like this:

vector<int> v;
// read v
auto solve = use_cache<bool(char, pair<int, string>)>([&](auto&& self, char c, pair<int, string> p) -> bool {
    // note that v was captured by &
    // use c, p, v as needed
    // let's say you have c1 and p1 as arguments for a recursive call
    auto x = self(c1, p1); // recursive call - do as many of them as needed
    // use c, p, v as needed
    return y; // return something
});
std::cout << solve('a', pair{1, "hello"s}) << '\n';

Caveats

The most important caveat is that since it uses a hash-table under the hood, you will often miss the performance that you get from just using multidimensional arrays. You can adapt the template to do things like that, but I didn't, for the sake of clarity and ease of implementation.

Since it doesn't make a lot of sense to store function calls with arguments that can change over time, the template doesn't support lambdas that take things by reference either. This is done in order to avoid any possible bugs that might come with references being modified on the fly somewhere in your code.

However, if for some reason (maybe for performance you want const refs of large structs/vectors instead of copies) you really want to use references, you can remedy that by doing the following:

• Wrap your arguments within std::reference_wrapper_t (for example, rather than int&, use std::reference_wrapper_t<int>) --- this makes a reference behave like a value (and is copyable for example).
• Provide a hashing implementation for std::reference_wrapper_t<T>.
• Avoid reference invalidation, i.e., the hash table should store values and not references, because references to temporary variables get invalidated during the run of the algorithm.
• Handle any other issues that might crop up, on your own.

Do let me know if you know of a better way of doing these things, and if there are any errors that might have crept into this post!

@online{easy-recursive-dp-template-2024,
  author    = {nor},
  title     = {Write recursive DP without thinking about memoization},
  year      = {2024},
  month     = {01},
  day       = {14},
  url       = {https://nor-blog.pages.dev/posts/2024-01-14-easy-recursive-dp-template},
}

• Introduction
• Why you should use lambdas
• Some context
• Hand-rolling our own lambdas
• C++ lambda syntax explained
• Using lambdas
• Using lambdas with the STL
• Some useful non-trivial patterns
• Some other interesting patterns
• Examples of competitive programming code using C++ lambdas

Prerequisites: knowing a bit about structs/classes in C++, member functions, knowing that the STL exists.

If you feel something is not very clear, I recommend waiting for a bit, because I tried to ensure that all important ideas are explained at some point or another, and if you don't understand and it doesn't pop up later, it is probably not that important (and should not harm the experience of reading this post). Nevertheless, if I missed out on explaining something that looks important, please ask me in the comments --- I'd be happy to answer your questions!

I would like to thank (in alphabetical order) AlperenT, bestial-42-centroids and kostia244 for discussions that helped improve the presentation and teachability of this post.

Introduction

A few years back, I co-authored a blog on pragmas because there were very few people who understood what pragmas do. I noticed that the same is true, albeit to a lower extent, for lambdas (C++ and otherwise) --- some using them as a minor convenience but nothing more; others having an irrational (and ignorant) disdain for them, mainly arising either out of some experiences that come from not using them properly or a love of all things "minimalistic".

Hence, part of the motivation behind this post is to show and convince people that lambdas can be very useful, both for your code AND your thought process, and that they will make your life easier if you do any amount of programming in a language that has decent support for lambdas (yes, not only C++). Thus, a significant part of the post would also talk about some topics related to models of computation and some history. And, of course, I will make a few philosophical arguments along the way, which you can feel free to skip, but they are helpful as a first step to realizing why such a change in perspective is quite important for any learning.

The other reason I am writing this post is to explain C++ lambdas on a much deeper level than people usually go into, without being as terse and unreadable for a beginner as the cppreference page --- this will involve rolling our own lambdas! This activity will also help us understand why certain behaviors are intuitive for C++ lambdas. And in the end, as everyone expects a tutorial on CF to be, we will also show some tricks that are especially useful in the competitive programming context.

Examples of usage of lambdas in code doesn't come until much later in this post, because we develop an understanding of what role lambdas actually play in a language, instead of just introducing them as nifty tricks that can help you shorten your code. If you want to only look at applications, please skip to the last few sections.

Hopefully, this post will also get people interested in programming language theory --- especially functional programming and parts that deal with language design.

Finally, no matter how experienced you are with lambdas/C++/programming languages, there is a high chance that you will find some piece of code/idea in this post that will look very new. I recommend checking out the two sections on patterns (in one of them we implement OOP using lambdas, for example), and the discussion on untyped v/s typed lambda calculus and implementing recursion.

Why you should use lambdas

I recommend reading this section again after reading the rest of the blog since it'll make more sense after you understand what lambdas are. But since the reader is probably growing restless about why they should be investing their time in lambdas, here's a list of reasons why you should learn about lambdas:

• Philosophical reasons: Imperfect as it may be, the Blub paradox implies that a programmer's way of problem-solving using code is upper-bounded by the language they use itself to the point that they can correctly realize how limited more primitive languages are, but fail to realize why any feature a higher level language gives them should help them as a programmer, and dismiss higher level languages as just their preferred language + some weird feature that they don't care about. Meanwhile, as people who know math, we probably already realize that thinking on a lower level than necessary is harmful to our development because we don't see the bigger picture. Think of it like having induction as a tool in our toolbox versus having to repeat an argument 1000 times to show that $P(1000)$ is true for some predicate $P$ --- this is what it feels like to code in a language that does not have for-loops, which a person who exclusively copypastes code to manually implement what a loop could have done would be very proud of. The moral of the story? Think on a higher level, code in whichever language you want to.
• More practical reasons --- You can define a lambda anywhere instead of functions that must be defined at namespace (global or otherwise) scope. So lambdas require you to scroll much less, prevent bugs, keep things local, and avoid polluting the namespace --- all of which are supposed to be good practices. They also reduce context switching that makes code bug-prone.
• You can store functions in data and pass functions more uniformly. This can be achieved by function pointers, too, but the other features make lambdas much more convenient for this purpose. It bypasses the need to make "tagged" versions of functions and implement your own vtable kind of things.
• You can store data inside functions! Instead of passing a value/reference as a parameter each time a function is called (for example, using the same dfs function for a local graph requires you to pass the local graph by reference to the dfs, which is inconvenient), you can just store (in C++ lambda language, "capture") the reference/value of a variable inside the lambda and be done with it.
• The standard library has a ton of support for lambdas, such as in sorting, binary searching, filtering, aggregating, etc. The usage is as simple as passing a single line lambda into a function provided by the STL.

Some context

The unusual name lambda comes from lambda calculus, which is a mathematical system for expressing computation, much like what a computer program is supposed to be written in. In this computation system, we have only three types of expressions, which are supposed to be the representation of each computation:

• terms of the form $x$: these correspond to variables.
• terms of the form $\lambda x. E$: this corresponds to a function that takes input $x$ and returns the result of evaluating $E$, which is an expression that may or may not involve $x$. In C++, this would roughly correspond to a function with parameter $x$ and function body return $E$.
• terms of the form $(E_1 \, E_2)$ where $E_1$ and $E_2$ are two expressions: this corresponds to applying the function represented by the expression $E_1$ to the argument $E_2$. In C++, this would roughly correspond to a function $E_1$ being called with $E_2$ as a parameter, i.e., $E_1(E_2)$.

And that's it. Note that there are no numbers and no restriction on what $E_2$ evaluates to. In particular, $E_2$ can be a function too! The same holds for $E$ and $E_1$ as well, so there are many kinds of expressions that you can write that will make sense in this "language". Evaluation of these expressions is done using certain rules called reductions (which resemble simplification of mathematical expressions), though at this stage, it is not really necessary to understand what they do (it is sufficient to take some amount of intuition from any language of your choice to develop an intuition for it, though care should be taken to avoid taking the intuition too far, because there are certain core concepts in languages that are simply not present in this lambda calculus --- for instance, types).

It turns out that this system of computation is Turing complete, i.e., any program that can be run on a Turing machine can be simulated using this method of computation. But why is this relevant to the discussion?

The second type of term here is called a lambda term. This is where the lambda terminology comes from --- because lambdas play the role of functions in this system. Except in lambda calculus, you're allowed to do a large variety of things by virtue of the lack of constraints in the definition. For example, you can pass around functions to other functions (remember that $E_2$ is not constrained to be of a particular "type").

But note that we are not allowed to manipulate functions in C++ as freely as the above definition dictates. For example, we are not allowed to return functions that depend on the input because function pointers in C/C++ are supposed to be pointers to things known at compile time.

To illustrate this, let's temporarily add numbers and the $+$ operator to the lambda calculus (by the way, they can be semantically simulated using just lambda expressions using what are called Church numerals, but that is a completely different story for another day). The following is a valid lambda expression:

$$\lambda x. \lambda y.(x + y)$$

This function takes a value $x$ and returns a lambda that takes an input $y$ and returns $x + y$. Note that the output of the inner lambda depends on the value of $x$. For example, $(\lambda x. \lambda y.(x + y)) (42)$ is just $\lambda y.(42 + y)$. So we have something analogous to a function that returns a function, such that the returned function is dependent on the input to the outer function. (By the way, this is what I meant by lambdas reducing the dependence on "tagged" functions, because you have a great tagging mechanism for lambdas --- just store the data inside it).

The corresponding in C++ style syntax should be something like (but this isn't legal C++ code, so I took the liberty of using non-standard syntax here):

int(int) lambda1(int x) {
    int lambda2(int y) {
        return x + y;
    }
    return lambda2;
}

So, there is a clear difference between C++ functions and lambda terms from the lambda calculus despite all the other semantic similarities. This discussion already hints to us what a lambda function (as we will call it from now on) should look like in C++.

Let's digress for the rest of this section into the discussion of functional programming languages.

Note that the imperative programming model (let's think about C for the sake of concreteness) is largely based on the Turing machine model of computation --- you have tapes (memory), pointers, and states. The main focus is on evolving the state of the program and the memory in order to get to an end goal.

The functional programming model, on the other hand, is largely based on lambda calculus. You rarely have any state in a functional programming language like Haskell or OCaml (especially in a purely functional language like Haskell). Instead, you express your code in the form of function applications and some basic inbuilt types (like integral types) and functions (like numerical operators).

Both of them are equally powerful. However, functional programming languages are often at a much higher level than imperative languages because of the power of abstraction and resemblance to mathematics, which rarely talks about state in any of its fundamental parts.

Also, a fun fact --- the sharp eyed reader would have noticed that the lambda function we wrote is semantically equivalent to a function that takes two numbers $x$ and $y$ and returns their sum, except that we have partial application for free, by "binding" $x$ to the lambda after the first application and returning a function that adds $x$ to anything. This style of writing lambda terms is called currying and can be used to implement multi-argument functions in a language where functions only have one argument.

This is just scraping the surface of what is otherwise a crazy set of things that can be done with lambda calculus. For example, one interesting thing you can do with it is to show how weird computation systems like the SKI combinator calculus are in fact Turing complete. Also, since the lambda calculus is Turing complete, there is a way (a quite elegant one at that) to represent recursion called a fixed point combinator, which can be implemented in multiple ways, one of which is the Y-combinator.

Hand-rolling our own lambdas

Since C++ is Turing complete, should we expect there to be a way to implement (a typed variant of) lambda calculus in C++? Definitely, though we probably shouldn't expect it to be very elegant. Or can we? Read on to find out.

Let's think about what a lambda function (shortened to lambda for convenience) should behave like in C++.

It should be what is called a "first-class citizen" of the language in programming language design --- i.e., all operations that are supported for other entities should also be supported for lambdas. In other words, it should have the following properties at the very least:

• Should be able to be passed as a function argument
• Should be able to be returned from a function
• Should be able to be assigned to a variable

The most general kind of thing that C++ supports that adheres to these rules is an object. Let's try to implement a lambda as an object in that case.

So for now, a lambda looks like this for us:

struct Lambda {
    // ???
};
Lambda lambda{};

Note that since structs can be defined in a local scope, we will be able to do whatever follows inside a local scope as well as a namespace scope.

Now according to its definition, we should be able to call a lambda as well. The most obvious way of associating a function with a struct is to implement a member function, let's say call. However, one cool functionality that C++ provides is the ability to overload operator() for a struct --- this is the function call operator, and it will help us reduce the syntactic boundaries between a function and an object. So rather than using the name call, we will overload operator(), which does the same thing but with a better syntax.

So, something like the following prints 2 in a new line:

struct Lambda {
    int operator()(int x) const {
        return x + 1;
    }
};
Lambda lambda;
std::cout << lambda(1) << '\n';

At this point, we should note that such a struct which overloads operator() is called a function object in the C++ standard (and is frequently informally referred to as the horribly named "functor" which has a very different meaning in category theory, so it will irk a lot of people if you call a function object a functor in front of them).

Now that we can wrap functions into objects, we can do whatever an object can --- for example, we can now return something that behaves like a function, so it might seem that the story ends here. However, note that we didn't implement anything that allows us to "bind" data to functions, as we wanted to do in our addition example. It is necessary to implement this, in order to make $E$ aware of the value of $x$ somehow, when applying $\lambda x. E$ to some $x$.

Since we want to emulate a mathematical language, for now we don't really care about C++ semantics, and we will choose value semantics for $x$ (which will make a lot of copies, but will make reasoning easier). This basically means that whenever we store $x$, it will be, just like in mathematics, completely independent of wherever its value was taken from.

Let's try our hand again at the $\lambda x. \lambda y.(x + y)$ example. Let's write it in a more computer-program-style syntax with parentheses at all the right places (which some people might recognize as being one infix-to-prefix transformation away from being Lisp code):

(lambda x.
    (lambda y.
        (x + y)))

Since there are two $\lambda$-s, we would need two structs this time --- one for the outer lambda and one for the inner lambda. The inner lambda needs to "capture" $x$, so we store a copy of $x$ in it whenever it is constructed.

struct LambdaInner {
    int x_; // our binding
    LambdaInner(int x) : x_{x} {}
    int operator()(int y) const {
        return x_ + y;
    }
};
struct LambdaOuter {
    LambdaInner operator()(int x) const {
        return LambdaInner(x);
    }
} lambda_outer;
LambdaInner lambda_inner = lambda_outer(1);
std::cout << lambda_inner(2) << '\n'; // or lambda_outer(1)(2)

But this starts looking less and less like actual lambda functions now. The trick is to use the fact that we are able to declare structs in local scope.

struct LambdaOuter {
    auto operator()(int x) const {
        struct LambdaInner {
            int x_; // our binding
            LambdaInner(int x) : x_{x} {}
            int operator()(int y) const {
                return x_ + y;
            }
        };
        return LambdaInner(x);
    }
} lambda_outer;
std::cout << lambda_outer(1)(2) << '\n';

Okay, this now resembles lambda expressions a bit more than before. But there is still a large amount of noise in the code --- for example, having to declare x_ and naming the structs for the lambdas. Turns out that we have exactly the tools for the job with C++ lambdas, which provide syntactic sugar for this kind of a thing:

auto lambda_outer =
    [](int x) {
        return [x](int y) {
            return x + y;
        };
    };
std::cout << lambda_outer(1)(2) << '\n';

Here, the lambda being returned has "captured" or "bound" the variable x by storing a copy of it inside itself.

Don't worry if you're a bit baffled with the syntax going from that monstrosity of object oriented code to this simple of a code, for now is the time to look at the syntax of a C++ lambda.

C++ lambda syntax explained

A C++ lambda expression (or lambda function), in its simplest form, has the syntax

[capture_list](parameter_list) specifiers -> trailing_return_type {
    // function body
};

where the trailing return type and specifiers are both optional (we will get to them in a moment, they're not super critical for now).

Given that lambda functions aim to replicate a lot of C++ function functionality, there is a lot of noise you could introduce here too, with syntax that I have not mentioned in the above --- you can make it something as complex as the following as of C++20 (even ignoring the possible *this and variadic captures):

int x = 1;
int y = 0;
auto lambda = [&, x = std::move(x)]
                <std::integral T>
                requires(sizeof(T) <= 8)
                (T a, auto b, int c)
                mutable constexpr noexcept [[deprecated]]
                -> std::uint64_t {
    y = x;
    return static_cast<std::uint64_t>(c) + a + sizeof(b) + x + y;
};

However, we won't be really concerned with a lot of this, and will only deal with a few special cases (besides, if you understand the rough correspondence between function objects and lambdas, it becomes more intuitive to guess how this syntax works).

In the syntax mentioned earlier, the lambda roughly corresponds to this struct (don't worry if you don't understand this yet, we will explain the terms used here in detail):

struct UnnamedLambda {
    // 1. variables corresponding to the capture list go here
    // 2. constructor for storing captured variables
    // 3. call operator - with some specifiers if specified:
    auto operator()(parameter_list) -> /* trailing_return_type, if any, goes here */ const {
        // lambda function body
    }
};

Note that the member function is marked const regardless of what we specify for the lambda --- this means that it is not allowed to do anything that mutates/is-allowed-to-mutate-but-doesn't the member variables. We can get past this restriction as we will see later.

Warning: this is only a representative correspondence and works well for almost all purposes (for example, the copy-assignment constructor of lambdas is deleted, but we didn't show it for the sake of simplicity). It is possible for the C++ lambda behaviour to diverge in some edge cases from the behaviour of this struct, but I haven't seen any such divergences.

For example, a lambda like the following:

int y = 1, x = 0;
auto lambda = [y, &x](auto a, int b) constexpr mutable -> int {
    return sizeof(a) * y + b * x;
};

corresponds to

struct UnnamedLambda {
    // captured variables
    int y_;
    int& x_;
    // constructor - constexpr by default if possible
    constexpr UnnamedLambda(int y, int& x) : y_{y}, x_{x} {}
    // call operator - the constexpr specifier marks this function as constexpr (a bit useless since it is constexpr whenever possible anyway), and the mutable specifier removes the const
    constexpr auto operator()(auto a, int b) -> int {
        return sizeof(a) * y + b * x;
    }
}

It is possible to template a lambda starting from C++20, but it is not something that is very useful for competitive programming, so I will omit it for the sake of simplicity, since the syntax has quite a lot of parts already.

Now let's look at every part in a bit of detail.

The capture list

Firstly, global/static variables and global constants don't need to be captured (and can't be) --- they are accessible without any captures and will always be usable inside a lambda like a normal variable. It is similar to being captured by reference by default for those variables.

Let's say we want to capture a variable y by value and x by reference (so in the struct, we store a copy of y and a reference to x). In that case, the capture list becomes y, &x or &x, y. We can do this for any number of variables in any order --- &x, y, z, x, &y, &z, w etc.

Now let's say you don't want to manually capture all variables that you're going to be using.

Let's say you want to capture all variables by value. The capture list becomes =.

And if you want to capture all variables by reference, the capture list becomes &.

But you'd say, I don't want to be stuck using the same semantics for all my captured variables. C++ has a way of allowing you to specify variables for which the default semantics are not followed.

If you want to capture all variables by value, but g by reference since it is a large graph, your capture list becomes =, &g (the default should be at the beginning of the capture list).

If you want to do the opposite and capture all variables by reference, but capture g by value, your capture list becomes &, g.

Now let's say that rather than capturing a variable directly, you want to store a value computed by a function, and all other variables should be captured by reference. Then your capture list becomes &, var = func_call(/* as usual */). This can be done for multiple variables. The semantics are the same as if you had done auto var = func_call().

Similarly, if func_call returns a reference, you can also use &var = func_call(). The semantics are the same as if you had done auto& var = func_call().

Note: when capturing a variable by reference and using lambdas after the variable has been destroyed, you will end up with dangling references where accessing that variable in the lambda is undefined behaviour, just like with any other usage of dangling references --- this is one of the reasons why I chose to capture by value instead of by reference when showing the 2 lambda example. Keep this in mind while using lambdas.

The parameter list

This is pretty much what you would use for any other function. In particular, there is also support for default parameters.

Also, it is noteworthy that the support for auto parameters was added to lambdas back in C++14, but was added for usual functions only in C++20. This shows how much simpler lambdas are for the language itself, when compared to functions. In the corresponding struct, this corresponds to a templated operator(), one for each instantiation that is needed.

So your lambdas can look like this (while compiling in C++14 as well):

bool f(int a, int b) { return a < b; }

int main() {
    int x = 1;
    int z = 0;
    auto lambda = [&x, y = f(1, z)](int a, auto b, int c = 1) {
        if (y) {
            x = c;
            return a + b;
        } else {
            return x - b + c;
        }
    };
}

The specifiers

For this section, it would be helpful to keep in mind our model of structs corresponding to lambdas, in order to understand how the specifier mutable helps, which we will explain below.

You might have noticed that we have not changed the captured value of any variable that we captured by value (the ones we capture by reference can mutate the variables they refer to, so a = b is possible for a being a reference captured variable). The reason is that with the correspondence, the call operator is const by default.

So, how would we mutate these variables? The answer is the usage of the mutable specifier --- the same keyword that helps you mutate a variable in a class when you are calling a function that is marked const.

We're now able to do something like this:

auto alternate_even_odd = [i = 0]() mutable {
    i ^= 1;
    return i;
};

When mutable is specified in a lambda, the const appended to the operator() is removed. This in turn allows us to mutate all captured variables (in this context it means calling functions/operators/member functions on them which require a non-const reference to them).

There are other specifiers --- constexpr (since C++17), consteval (since C++20) and static (since C++23), but they would not be very useful in a competitive programming context, so we omit them.

The trailing return type

Notice that the default syntax for a lambda doesn't have a return type, but the syntax for C++ functions has a return type.

In fact, you can have auto return type for C++ functions starting from C++14, and the type is deduced using some type deduction rules. By default, these rules apply for lambdas as well.

However, it is possible to have certain ambiguities/underspecification, like the following:

auto f = [](int64_t x) {
    if (x < 0) return 0;
    return x;
};

or

auto f = [](auto g, int x) {
    return g(g, x);
};

In the first, the compiler is unable to deduce whether the lambda's return type is supposed to be int or int64_t.

In the latter, since the type of g is unknown, it is also unknown what g returns.

In such cases, we must either cast the return values to a certain type, or specify the return type on our own, like the following:

auto f = [](int64_t x) -> int64_t {
    if (x < 0) return 0;
    return x;
};

auto f = [](auto g, int x) -> int {
    return g(g, x);
};

Using lambdas

Okay, now that we have finally shown what the lambda syntax can do in C++, we are yet to use them in any application.

In order to use them, we need to know how to do the following, since the type of the corresponding structs of two different lambdas can be different (and the types of two separately defined lambdas are indeed different in C++):

• Defining lambdas
• Passing lambdas
• Storing lambdas

Defining lambdas

This is very easy, as we have already seen before:

auto f = [](){};

And a cool trick that I didn't mention earlier is that if your parameter list is empty, you can simply drop the ().

So the shortest lambda definition looks like this:

auto f = []{};

Passing lambdas

In C++20, you can do this:

void print_result(int x, auto f) {
    std::cout << f(x) << '\n';
}
void print_result_1(int x, auto& f) {
    std::cout << f(x) << '\n';
}
void print_result_2(int x, auto&& f) {
    std::cout << f(x) << '\n';
}

A small nitpick: the last one is better if you want to pass a lambda by reference if it is an lvalue (informally, something that has an address), but by value if it is not. For example print_result_2(2, [](int x) { return 2 * x; }); and print_result_2(2, some_lambda); both work, but the first of these doesn't work with the print_result_1.

When passing a lambda to a lambda, the above syntax works even for something as old as C++14.

In older standards of C++, like C++11/14/17, you can do this (the & and && variants still work, but I omitted them for the sake of not having too much code):

template <typename Func>
void print_result(int x, Func f) {
    std::cout << f(x) << '\n';
}

Storing lambdas

This is something that competitive programmers rarely do, but when they do, a lot of them add unnecessary overheads mostly due to lack of understanding of lambdas/templates.

Firstly I will show how people end up storing lambdas:

struct Storage {
    template <typename Func>
    Storage(Func f_) : f{f_} {}
    // or Storage(auto f_) : f{f_} {}
    // or Storage(std::function<int(int)> f_) : f{f_} {}
    std::function<int(int)> f;
};
Storage storage([](int x) { return x * 2; });

Other people use this very limited version (we'll get to why it is limited):

struct Storage {
    using F = int(*)(int);
    Storage(F f_) : f{f_} {}
    F f;
};
Storage storage([](int x) { return 2 * x; });
// Storage storage(+[](int x) { return 2 * x; }); also works, relies on decaying from a lambda to function pointer

The most natural way, however, is to do either this:

template <typename F>
struct Storage {
    Storage(F f_) : f{f_} {}
    F f;
};
Storage f([](int x) { return 2 * x; })

or

auto make_struct = [](auto f_) {
    struct Storage {
        std::remove_reference_t<decltype(f_)> f;
    };
    return Storage{f_};
};
auto s = make_struct([](int x) { return 2 * x; });

For the sake of convenience, let's name these v1, v2, v3 and v4.

v1 seems to be the most generic way, but has unnecessary overhead if you don't need to do something like making a vector of lambdas. The reason it works is that std::function "erases" the type of the lambda (with a technique called type erasure), but to do that it needs heap allocation and other overheads, and often is unable to optimize the code in the lambda that interacts with the outside (for instance, recursion). Meanwhile, lambdas are able to be optimized as much as, if not faster than, usual functions, since structs are zero-cost abstractions. I have seen spectacular slowdowns with v1 (50x sometimes) due to lack of optimizations, and I'm of the opinion that unless necessary, type erasure should never be used in a context where performance matters. Of course, no kidding, type erasure is an engineering marvel that deserves its own post, and std::function, as an extension does so too.

v2 falls back to the concept of a function pointer, which exists since the old days when C was all the rage. It works decently fine in practice, but has a couple of issues:

• It is impossible to cast a lambda that has a capture to a usual function. This should be clear when we think about how a lambda can be represented as a struct. The very fact that a lambda can be converted to a function pointer is a surprise if you know how lambdas are implemented.
• Function pointers suffer from having to use one more indirection than necessary, due to the function call not being known "by the struct". Still better than std::function in terms of speed, though.

v3 solves all the above problems, in the case you don't need to be able to store the container in a vector. The only drawback is that since it is a templated struct, it can not be defined in local scope, as much as we want to. The reason is that in many implementations, symbols in a template must have external linkage, and this is simply impossible for something in a local scope. There is another minor drawback, which is an inconvenience at best --- since partial template specialization is not allowed in C++, you must rely on CTAD (class template argument deduction) to make your code shorter. Otherwise you would have to do something like

auto f = [](int x) { return 2 * x; };
Storage<decltype(f)> s(f); // or std::remove_reference_t<decltype(f)> to remove the reference that comes attached with decltype on an lvalue

Coming to v4 --- it does all the things that the other solutions do, and since it is a lambda, it doesn't suffer from the issues that templates do.

As it turns out, v4 is also the most "functional" implementation out of all of them, because you are literally just using functions and nothing object oriented is required.

Is the fact that v4 is the most convenient out of the above 4 just coincidental? I think not.

Anyway, partly since all my library code had been written many years ago, I use v3 for my competitive programming library code --- for instance, my implementation that modifies and generalizes the AtCoder library code for lazy segment tree can be found here, starting at line 393. As an aside, it is one of the fastest implementations for that problem, and it used to be the fastest for a very long time until a couple of months ago, and is off from the fastest solution by a few ms. The current fastest solution also uses the v3 pattern for making things generic.

But for anything new, I like using v4 --- it is functional and flexible.

The verdict:

• Use v1 whenever you need type erasure but can't do without captures
• Use v2 whenever you need type erasure but can do without captures
• Use v3 whenever you don't need type erasure, but want a classical struct definition somewhere, and want all the performance
• Use v4 whenever you don't want type erasure and want your code to be flexible and not depend on CTAD.

Using lambdas with the STL

As promised, here are some applications of lambdas with some of the STL algorithms/data structures.

Since STL algorithms are implemented mainly as functions or function-like objects, the main use of lambdas is as callbacks to the functions. We are able to pass lambdas as one of the parameters of the STL functions in question, and the lambda is called inside the body, which is why it is a callback.

It is also possible to use them in STL containers during construction.

For the precise functionality of the functions I mention below, I would recommend reading about them on cppreference.

Lambdas are used in multiple forms:

Comparators

A comparator is something that returns the result of comparison of its inputs. It is used in the following:

• sorting: std::sort(l, r, comparator); where the comparator tells whether $a < b$ or not for inputs $a$ and $b$.
• binary_search/lower_bound/upper_bound/heap operations/set intersection etc.: similar to sorting.
• next_permutation: finds the next permutation according to an order provided by a predicate.
• containers (map/set, unordered_map/unordered_set): for the constructor for ordered versions, we can pass a lambda that tells when $a < b$ for inputs $a$ and $b$, and for the unordered versions, we can pass a lambda that tells when $a = b$ for inputs $a$ and $b$.

Predicates

A predicate is something that decides whether some condition is true or not, based on its inputs. It is used in the following:

• partition_point --- returns the point $p$ in a range $[l, r)$ such that $f$ is true on $[l, p)$ and false on $[p, r)$.
• filtering and filtering-based algorithms:
  • find_if/find_if_not --- returns the first position where the predicate is true/false (also see find_last_if/find_last_if_not)
  • default_searcher, boyer_moore_searcher, boyer_moore_horspool_searcher --- used in std::search to search for a pattern based on the predicate
  • copy_if/copy_if_not --- copies all things on which the predicate evaluates to true/false
  • remove_if/remove_if_not --- similar to copy_if/copy_if_not but removes elements instead
  • and others, which are too numerous to list in a blog post

Generators/transformers

• std::generate expects a function object --- usually a lambda --- and assigns the result of successive calls to every element in the input range. To implement this, a solution using stateful lambdas is the following:

std::generate(l, r, [i = 0]() mutable { return i++; });
// the same as std::iota(l, r, 0);

There is a more idiomatic solution using coroutines, but coroutines in C++ allocate on the heap.

• std::transform expects a function object and for each $x$ in a range, updates the corresponding position in another range with $f(x)$.

Hash functions

• unordered maps/sets, boyer_moore_searcher, boyer_moore_horspool_searcher all expect a hashing function to be implemented (if not, they fall back to std::hash), and this should be passed during construction.

n-ary operators

• std::accumulate and std::reduce expect you to have a binary operator (by default, std::plus) to be able to aggregate over a range
• std::partial_sum does the same, but stores values for every prefix sum
• the multitude of inclusive/exclusive_scans and their transform variants also do something similar.
• std::inner_product allows you to pass two different binary operators (one being an analog for +, the other for *).
• std::adjacent_difference does the opposite of std::partial_sum, but in a different order, and expects a function object to be called as the difference operator.

Some useful non-trivial patterns

Immediately invoked lambdas

Consider this situation: you have to initialize some data (let's say some result of precomputation), but you want to

• keep it local, because global scope usually leads to potentially buggy code
• avoid polluting your scope with unnecessary variables, in order to prevent bugs with the same variable

The concept of an immediately invoked lambda comes in here.

In a nutshell, the idea is that we would like to make a new nested scope for it, but scopes are not expression while lambdas are.

So your solution would earlier look like this:

std::vector<int> a;
{
    // process and modify a
}

and it becomes this:

auto a = [&] {
    std::vector<int> a;
    // process and modify a
    return a;
}(); // notice these parentheses

There are a couple more benefits to this, arising out of the fact that we have now managed to convert a scope into an expression.

So we can do the following easily:

• Complicated initialization can easily be done in the constructor like this (more useful for real life code than competitive programming):

struct A {
    A(size_t n, int val) :
        a{[&] {
            std::vector<int> v(n);
            std::fill(v.begin(), v.end(), val);
            return v;
        }()} {}
    std::vector<int> a;
};

• Make variables with potentially complicated initialization const if mutation is not needed --- this is somewhat of an extension of the previous point, and it often leads to optimized code, even if we ignore the number of errors we would save at compile time.

• Precompute and assign at compile time --- if we have an array to precompute, we can do it at compile time globally like this:

auto precomputed_array = [] {
    std::array<int, 10000> a{};
    // preprocess
    return a;
}();

Since lambdas are constexpr by default, if everything inside the lambda is constexpr-friendly, the compiler will try to perform this lambda call at compile time, which will in general be faster than computing stuff at runtime, and the compiler can also reason about the data that it has generated at compile time, so it even makes the rest of the program faster.

One small drawback (for Codeforces) is that if there are too many operations in the lambda, you will risk getting a compile time error (telling you to increase your compiler's constexpr operations limit --- for which I have not yet been able to find a way from within the source code).

The compiler is doing the best it can (and the assembly for constexpr-ed code will be much faster than the assembly for non-constexpr-ed code, simply because what is left to run is the bare minimum possible), and for the compiler, there is no limit on computational resources other than the ones due to the machine. Unfortunately, this doesn't work out for practical purposes like contests, where compile-time and system limitations (which include compiler limits that are built into it, but can be changed).

One hacky workaround is:

auto something = [] {
    int a; // note that it is not initialized, only declared, so it is not constexpr friendly. so the compiler will not constexpr it. it is definitely a code smell, but what can we do?
    // rest of the function
}();

This is a workaround that I have been using for a long time now, as a way to prevent things from getting constexpr-ed at compile time. Don't do this in real-life code though.

Recursive lambdas

We can implement recursion in a Turing machine, but can we do so with lambdas? Recall that we noted that the Y-combinator is a way to do precisely this thing in an untyped lambda calculus.

We can write a somewhat similar analog for it in C++ lambdas too, using the C++14 feature that allows us to have auto arguments.

auto fib = [](auto self, int n) -> int {
    if (n <= 1) return n;
    return self(self, n - 1) + self(self, n - 2);
};
std::cout << fib(fib, 10) << '\n';

(If you want to be more efficient in the general case, consider using auto&& instead of auto).

Let's look at how we came up with this implementation.

We don't have a way to refer to the unnamed lambda inside itself with C++ syntax (and the lambda calculus syntax).

So what is the next best thing we can do? Yes, just make a dummy parameter that will (whenever it should be used) be itself, and remember to call the defined lambda with itself whenever it needs to be used. This is precisely what the above code does.

As a fun exercise, let's try writing a function that takes a lambda, which has 2 arguments --- one referring to itself, and the other being what it should call (and will eventually become itself). Our target would be to do something like the following:

auto lambda = [](auto self, int n) {
    // something
    // the recursive call is of the form self(n - 1)
};
auto rec_lambda = add_recursion(lambda);
std::cout << rec_lambda(10) << '\n';

We will ignore all considerations of performance for now, and make copies of everything, for ease of presentation.

Let's make a function object that provides an overload for operator(), and abstracts out the self(self, ...) calls into just self2(...) calls --- then we can use self2 as the self parameter in the original lambda's definition, and the double recursion (which should ideally be optimized away) will allow us to do what we want.

template <typename F>
struct add_recursion_t {
    F f;
    template <typename X>
    auto operator()(X x) {
        return f(*this, x);
    }
};
template <typename F>
auto add_recursion(F f) { // could have as well been implemented as a lambda
    return add_recursion_t{f};
}

This is also what the std::y_combinator proposal does, but with better optimizations that sadly renders the code less than readable. This paper is redundant with the C++23 feature called "Deducing this" (which also solves a lot of other problems, not limited to lambdas).

To avoid writing self so many times, it allows us to refer to the lambda itself in its body, and write

auto fib = [](this auto&& self, int n) { // notice that the -> int is gone
    if (n <= 1) return n;
    return self(n - 1) + self(n - 2);
};
std::cout << fib(10) << '\n';

You can test this code out on the latest Clang release.

But can we do this in just lambdas? The answer is

Stateful lambdas

Have you ever wanted a Python generator in your code? Turns out that with mutable state, you can implement stateful lambdas that work in a similar manner.

It should be abundantly clear with the std::generate example we used a while back that stateful lambdas are nothing but objects with a single member function accessible via the call operator, and some mutable state represented by the data captured by them. It is helpful to remember the struct-to-lambda correspondence here.

For instance, let's say you want to print something that looks like a tuple, and std::apply works on it.

How would you print its space separated members?

std::apply([i = 0ULL] (const auto&... x) mutable -> void {
    (((i++ ? (std::cout << ' ') : void()), std::cout << x), ...);
}, tuple_object);

Here we have made abundant use of fold expressions, but the main point is that after expansion, this mutates the state of i inside the body each time there is an i++, and a space is printed before every element except the first element.

Similarly, you can write a random number generator as follows (taking the example from here):

auto next_random = [
    splitmix64 = [](uint64_t x) {
        x += 0x9e3779b97f4a7c15;
        x = (x ^ (x >> 30)) * 0xbf58476d1ce4e5b9;
        x = (x ^ (x >> 27)) * 0x94d049bb133111eb;
        return x ^ (x >> 31);
    },
    FIXED_RANDOM = chrono::steady_clock::now().time_since_epoch().count(),
    random = 0
] () mutable {
    return random = splitmix64(random + FIXED_RANDOM);
};

while (n--) std::cout << next_random() << '\n';

If you want to, it is also possible to write all of your code in a single immediately-invoked lambda, but that is something I discourage you from writing, unless you want to obfuscate code or just want to challenge your brain.

For example, this code for the latest Div2A works, but I definitely do NOT recommend that you write code this way. However, it is quite instructive to understand why this code works and why certain variations do not, so I definitely DO recommend reading and understanding this --- it'll help cement your understanding of how captures work, what is called when, and so on.

#include "bits/stdc++.h"

int main() {
    [rd = [] {
         int x; std::cin >> x;
         return x;
     },
     wt = [](auto x) { return (std::cout << x, 0); },
     sorted = [](auto x) {
         std::sort(x.begin(), x.end());
         return x;
     },
     forn = [](auto f, int n) {
         while (n--) f();
         return 0;
     }] {
        [&, _ = forn(
                [&]() {
                    auto n = rd();
                    auto k = rd();
                    [&, a = std::vector<int>(n)]() mutable {
                        [&, _ = std::generate_n(a.begin(), a.size(), rd)]() {
                            [&, ans = (k == 1 && a != sorted(a) ? "NO\n" : "YES\n")]() {
                                [_ = wt(ans)]() {
                                };
                            }();
                        }();
                    }();
                },
                rd())]() {
        }();
    }();
}

Some other interesting patterns

Using lambdas for implementing classes

Note that we claimed that lambda calculus is Turing complete. But can it implement classes? The answer is of course yes.

Can C++ lambdas implement classes? Also yes.

Let's let go of the implementation of lambdas in C++ for now, and think of implementing objects in terms of functions.

For implementing classes, we need data and member functions. For data, we can just store the data as a capture in a lambda. But what does the lambda do? We should be able to call something using the captured data, so the lambda should take as a parameter whatever the implementation of the member function should be.

So, once we have an object, we can call the data with the function, instead of calling the function on the data.

// constructor
auto range = [](size_t l, size_t r) {
    return [l, r](auto f) {
        return f(l, r);
    };
};
// (free) member functions
auto len   = [](size_t x, size_t y) { return y - x; };
auto right = [](size_t x, size_t y) { return y; };
auto left  = [](size_t x, size_t y) { return x; };
// usage
auto a = range(1, 5); // this is an object
auto len_a = a(len);  // compare with a.len() in usual C++ syntax

And if we want to support recursive functions, we can change the definitions a tiny bit.

auto range = [](size_t l, size_t r) {
    return [l, r](auto f) {
        return f(f, l, r);
    };
};
auto len   = [](auto self, size_t x, size_t y) { return y - x; };
auto right = [](auto self, size_t x, size_t y) { return y; };
auto left  = [](auto self, size_t x, size_t y) { return x; };
auto depth = [](auto self, size_t x, size_t y) {
    if (y - x <= 1) return 0;
    return 1 + self(self, x, x + (y - x) / 2);
};

auto a = range(1, 5);
auto len_a = a(len);

Mutual recursion can also be implemented similarly, but would require much more effort. Do let me know if you find some way to implement mutual recursion in a clean manner!

Inheriting from lambdas

template <typename... T>
struct S : T... {
    template <typename... L>
    S(L&&... l) : T(std::forward<L>(l)...) {}
    using T::operator()...;
};

This can be used to implement a somewhat generic lambda by providing different implementations like this:

S generic_lambda = {
    [](int x) { return 1; },
    [](double d) { return 0.0; }
};
std::cout << generic_lambda(0) << '\n';
std::cout << generic_lambda(1.0) << '\n';

But we already have generic lambdas in C++20, and they're pretty interesting in themselves.

Examples of competitive programming code using C++ lambdas

Finally, let's come to some useful code patterns involving lambdas that I use (and used to use) while solving problems.

As a local function

This seems to be the most popular usecase for lambdas, and for good reason --- you can avoid code duplication by literally making a code block executable (the & capture does wonders for this usecase). It ends up being particularly useful in the following scenarios:

• When you have to implement a function for a certain query, but it will be used multiple times, perhaps with slightly different behaviours.
• When you are implementing a data structure inline --- i.e., when you don't have library code at hand, and want to avoid having to declare a struct for, say, a segment tree or a Fenwick tree or a DSU.
• When you want to avoid rewriting annoying bits of code like when you are writing code for an interactive problem, where the input/output format is complex (even for a very basic format, you need to print, flush, read and return, which deserves a function of its own).

For example, although the intent is not very clear in this example (unless we try solving the problem itself), it is clear that there would have been a lot of code duplication without the use of a lambda --- just count the number of calls to the lambda.

DFS and other applications of recursive lambdas

Most people implement DFS as a function, and to do that, they make their graphs global too.

What happens when we want to do a multi-test problem? Clear graphs each time? Of course that has the potential to be buggy.

So what some other people do is to make graphs local, but pass them as a parameter. Similarly, if they want to update any arrays/vectors/integer, like visited/color/component/n_components, they also pass them as a parameter.

Why is this bad? If you swap out two arrays/variables in the references, it would not be a very obvious bug. And it just increases your context switch, because now you have to care about every function call. So if you are implementing a particularly involved DFS, you will end up being more prone to bugs than you could bargain for.

Some smart people realized this and started using local lambdas for DFS, but they used the following trick (which is still not the best trick, I'll explain why in a moment):

std::function<int(int, int)> dfs = [&](int u, int p) {
    int sum = 1;
    for (auto v : g[u])
        if (v != p) sum += dfs(v, u);
    return sum;
};
int sz = dfs(0, -1);

Why it is not the best approach:

• Typing the types twice is too much work
• Type erasure (yet again) makes recursive functions quite slow. It might not be visible for DFS, but once you start using it for something like divide and conquer or recursive DP that needs of the order of $10^7-10^8$ recursive calls, the performance hit would almost invariably make your solution too slow to get AC.
• No support for default parameters --- some might see this as a good thing, but the point is that it is abstracting away too much detail from the lambda.

Here's what I use:

auto dfs = [&](auto self, int u, int p = -1) -> int { // can also be auto&& if you want to be careful
    int sum = 1;
    for (auto v : g[u])
        if (v != p) sum += self(self, v, u);
    return sum;
};
int sz = dfs(dfs, 0);

Some very high rated programmers use this pattern too, for example, this submission, and for good reason --- it pretty much always compiles down to the most optimal code (according to the compiler). The only case I know of this being slower than a usual implementation was because the compiler was vectorizing the DFS(!) and was leading to instruction cache misses. That was a very peculiar case, and I don't expect it to encounter it again in the wild, especially not in a problem with a tight TL.

Others use the idea outlined in the now-redundant std::y_combinator proposal, and do something like this:

// template code
template <class Fun>
class y_combinator_result {
    Fun fun_;
  public:
    template<class T>
    explicit y_combinator_result(T &&fun): fun_(std::forward<T>(fun)) {}
    template<class ...Args>
    decltype(auto) operator()(Args &&...args) {
        return fun_(std::ref(*this), std::forward<Args>(args)...);
    }
};
template<class Fun>
decltype(auto) y_combinator(Fun &&fun) {
    return y_combinator_result<std::decay_t<Fun>>(std::forward<Fun>(fun));
}
// actual code
auto dfs = y_combinator([&](auto self, int u, int p = -1) -> int {
    int sum = 1;
    for (auto v : g[u])
        if (v != p) sum += self(v, u);
    return sum;
});
int sz = dfs(0);

For instance, this submission.

In fact, this is such a popular pattern that some high-rated people put it on top of their bare minimum templates as well, for instance, here.

The one drawback for this template is that sometimes the compiler is not able to reason through all the abstraction, and the code generated might be slightly slower. This is fortunately not the case for most cases, but there is a visible overhead difference in a few cases I have seen.

Interfacing library code

Library code should ideally be hidden away in a header file, but since most online judges don't have header file support, we are forced to write library code before any of the actual code begins.

It is also important to ensure that after copypasting library code into your submission, there is absolutely no change that you need to do in the library code unless it is a fundamental difference from the logic of the data structure/algorithm, and you just happen to have all the code at hand. Otherwise, you would be editing a large piece of code that you might have forgotten the details/quirks of, and it is easy to end up with bugs.

To do this, it is quite important to implement your library in a way that is as generic as possible. And there are few things more generic than allowing your data structure to execute arbitrary code.

Hence, it makes for a really good choice to use a lambda as a customization point. In fact, the C++ standard calls certain types of function objects "customization points" which goes on to show that interfacing into library code with functions/function objects is a well-understood/well-adopted design practice that is also very convenient for library usage.

As an example of such a thing, my implementation that modifies and generalizes the AtCoder library code for lazy segment tree can be found here, and it uses lambdas as possible customization points. It not only implements lazy segment trees (with some opt-in optimizations), but it also has functionality for normal segment tree, with barely any overhead compared to a usual segment tree implementation.

Algorithms with custom predicate/aggregation function

This is in fact one of the most common applications. There are countless lines of code among codeforces submissions that essentially sorts an array according to a given predicate: for instance, this code.

There are also a very large number of binary search submissions that follow the template "define a predicate, do binary search on it" --- for instance, this code. Note that the manually written binary search could have been avoided by using std::partition_point as well, but it is not very popular for some reason.

Prefix and suffix sums (usual addition or multiplication or xor) can be implemented using std::partial_sum using lambdas as well.

Please let me know if there is anything I missed out, and constructive comments on the content in general are welcome!

@online{lambdas-cpp-and-otherwise-2023,
  author    = {nor},
  title     = {On lambdas, C++ and otherwise: the what, the why, and the how},
  year      = {2023},
  month     = {12},
  day       = {02},
  url       = {https://nor-blog.pages.dev/posts/2023-12-02-lambdas-cpp-and-otherwise},
}

Disclaimer: I use ++i much more often in code. But i++ has its own place, and I use it --- and the generalization I mention --- quite frequently wherever it is a sane choice.

Is ++i better than i++?

A lot of people are taught that since i++ also returns the old value of i before the increment, it needs a temporary, and hence it must be slower. Good news: almost all compilers today optimize this part away whenever this behaviour is not needed, and the difference between i++ and ++i doesn't matter.

So what's the difference? In C++, turns out that apart from this old/new value difference, there is another difference.

Any expression in C++ that looks like a op b= where op is a binary operator in fact "returns" a reference to the variable a after completing the operation. As a result of this, you can do things like this:

// replaces x by a * x % p
void mod_mul(int64_t& x, int a, int p) {
  (x *= a) %= p;
}

Turns out that since you only need the value after the increment for the pre-increment operator, it is possible to have similar behaviour there too, and that is precisely what C++ chose to do:

// replaces x by (x + 1) % p
void mod_inc(int64_t& x, int p) {
  ++x %= p;
}

However, the post-increment doesn't enjoy any of these properties. Perhaps this is why the Google C++ Style Guide (which I don't really like all that much, but will just quote here) recommends

Use the prefix form (++i) of the increment and decrement operators unless you need postfix semantics.

Another part of the language where you can see this distinction in practice is when you overload pre-increment and post-increment operators for a class:

struct Int {
  int value{};
  Int& operator++() {
    std::cout << "pre-incrementing\n";
    ++value; return *this;
  }
  Int operator++(int) {
    std::cout << "post-incrementing\n";
    Int temp = *this;
    ++value;
    return temp;
  }
};

If you notice closely, the return type of the pre-increment overload is a reference, which is not the case with the post-increment overload. Using a post-increment also makes a copy, so if you're using a post-increment on a struct/class object that defines both, it is likely that there is a potential performance improvement lying right there.

So, is there any legitimate use-case for post-increment?

Indeed, there is. Notice how in the post-increment code in the previous example, we had to store a temporary. This gives us a hint as to where exactly post-increment is useful: when you need to avoid temporary variables! And one of the places where temporary variables are not needed is when an operation (in this case, increment) must be done after any use of a value.

An example to illustrate this point comes when you want to implement copying of a C-style, null-terminated string (without copying the null terminator so that you're able to, let's say, concatenate strings into a buffer). Let's say we didn't have post-increment in the language at all. The algorithm looks like this:

void copy_c_string(const char* input, char* output) {
  while (*input) {
    *output = *input;
    ++input;
    ++output;
  }
}

The first thing one would say is that there are too many lines of code --- you need to check input, need to separately handle input and output pointers, and if someone is refactoring this code and accidentally deletes one of the increments, they will introduce a bug that is hard to find in a large codebase.

Contrast that with the following:

void copy_c_string(const char* input, char* output) {
  while (*input) {
    *output++ = *input++;
  }
}

The intent of moving the pointer forward immediately after every use (and using it exactly once, too) is perfectly conveyed, we don't have too many lines of code, and all is well. Of course, it takes some time getting used to writing/reading this kind of code, but thinking of it in terms of "immediate operation after use" shows that it works analogously to what RAII is to a manual destructor call.

In fact, the usage of post-increment and pre-decrement (not pre-increment) was (and is) so popular (partly due to widespread use of half-open ranges), that certain architectures in the past had special functionality for them (for example, this). Thus, in some rare cases, it is imperative to use post-increment instead of pre-increment for performance.

Do we have an op= style (compound assignment) generalization for post-increment?

Yes, we do. It is called std::exchange.

What it does is this --- std::exchange(a, b) returns the old value of a after setting it to b. So i++ is the same as std::exchange(i, i + 1) in terms of semantics.

Similarly, a = std::exchange(b, a) swaps the values of a and b, which shows that it is more general than std::swap, though maybe at a small performance hit for types more complicated than a simple integer. Adding a bunch of =std::move=s should fix that to some extent, though.

Why the strange name? How do I remember it?

I consider this to be a naming disaster, and believe that if there was a better succinct name that does NOT imply bidirectional flow of data, the C++ committee would probably have tried to do it.

The way I remember it is a = std::exchange(b, f(a, b)) is (morally) equivalent to std::tie(a, b) = std::make_pair(b, f(a, b)) --- that is, the assignments are done at the same time. So somewhat like storing temporaries for everything that is to be assigned, and then performing the assignments at the same time.

A more general example is a = g(a, std::exchange(b, f(a, b))) which does std::tie(a, b) = std::make_pair(g(a, b), f(a, b)) --- in a mathematical sense, it allows you to do two parallel assignments in a linear chain-like syntax. I believe this is what brings about the exchange naming (if not the CMPXCHG instruction).

A more intuitive way to read A = std::exchange(B, C) is that A becomes B and B becomes C at the same time.

Some competitive programming relevant examples

Fibonacci/linear recurrences

Writing a = std::exchange(b, a + b) is much easier and less error-prone than auto tmp = a; a = b; b = tmp + b; (in fact, someone pointed out that the initial version of this code was wrong). The same goes for any other linear recurrence in 2 variables.

Iterative GCD and extended GCD

Since the Euclidean GCD algorithm is also an affine transformation (especially one where you swap after update), the implementation goes from the less readable/intuitive

std::array<T, 3> extgcd(T a, T b) {
    std::array x{T{1}, T{0}};
    while (b) {
        std::swap(x[0] -= a / b * x[1], x[1]);   // x[0] = x[1], x[1] = x[0] - a/b * x[1]
        std::swap(a %= b, b);                    // a = b, b = a % b
    }
    return {x[0], x[1], a};
}

to

std::array<T, 3> extgcd(T a, T b) {
    std::array x{T{1}, T{0}};
    while (b) {
        x[0] = std::exchange(x[1], x[0] - a / b * x[1]);
        a = std::exchange(b, a % b);
    }
    return {x[0], x[1], a};
}

Lazy updates in buffers (use-and-clear)

It is usually error-prone to clear a buffer of, let's say, updates that you want to process, in the very end of the processing function, as follows:

void flush() {
  for (auto x : updates) {
    // do something
  }
  updates.clear(); // easy to forget
}

Sometimes this might lead to a MLE as well, if this flush function is in fact a DFS that is called in a loop after processing the updates, where the graph is built during the function itself, and the memory limit is low or the structure you store inside the buffer has quite a lot of information.

To be able to deal with the first of these issues, people used something of the following sort:

void flush() {
  std::vector<Update> updates_tmp;
  using std::swap; swap(updates_tmp, updates);
  for (auto x : updates_tmp) {
    // do something
  }
}

This faces multiple issues

• You need to create and assign a temporary, and also need to remember the type of the updates variable (can you see where we are going with this?)
• The temporary exists till the end of the function, so this doesn't fix the second issue.
• Initializing/declaring and then modifying is a very non-functional (anti-)pattern, and making it a habit in code will almost invariably lead to state-mutation-related bugs.

Consider the following solution using std::exchange:

void flush() {
  for (auto x : std::exchange(updates, {})) {
    // do something
  }
}

Which of these two implementations mirrors the intent of the original function? And which one would you choose to write yourself?

Some software engineering relevant examples

Implementing move constructors and assignment operators

While defining move semantics for your class, it is usually a good idea to keep the moved-from object in defined state. Sometimes this might even be necessary, for instance, when you want to implement something with semantics like std::unique_ptr.

Avoiding redundancy.

It is possible to avoid having to implement post-increment when pre-increment is already available by just doing return std::exchange(*this, ++Type{*this})

Acrobatics with locks

The "immediately do after use" idea also carries over to when you're using locks --- it is clearly optimal to use locks for as short a time as possible, when comparing across the same kinds of software architecture. One way that std::exchange can be used to this effect is to use a scoped lock inside a lambda, that returns std::exchange(resource, resetted_resource).

In fact, there is a common primitive in lock-free programming that uses the exchange idiom (compare-and-swap, test-and-set, std::atomic_exchange).

Generic programming with iterators

Sometimes the only way to increment an iterator is std::next. Using std::exchange, we can implement our own version of post-increment to be able to write generic code using iterators. Since iterators are very general, you might find yourself using this trick in very unexpected places too.

Please let me know what you think about this C++ feature and if there are any mistakes in the above post. Comments are welcome!

@online{std-exchange-cpp-2023,
  author    = {nor},
  title     = {Avoiding temporaries - generalizing i++ using std::exchange},
  year      = {2023},
  month     = {11},
  day       = {27},
  url       = {https://nor-blog.pages.dev/posts/2023-11-27-std-exchange-cpp},
}

Some might argue against adding a library on Codeforces, but for them, I recommend viewing this post as an educational resource on some of the library's features that I find cool.

There are a lot of things in the STL in the newer C++ standards, whose implementations were originally inspired from Boost, so you could be able to use some features that might not be available until the next few C++ standards.

As of now, the latest version of Boost is 1.83.0, and its documentation can be found here.

Here are a few features from Boost that are pretty useful for competitive programming:

1. Algorithms from Boost.Algorithms --- this includes algorithms like KMP and binary exponentiation (power for arbitrary associative operations) as well. It also makes for much cleaner code and with significantly less effort. It also includes some "mini" algorithms that are annoying to write, that one might use in some technical contexts (for example, gather is an algorithm like this, and gets used a lot in divide and conquer problems). There are some algorithms that ended up in the STL, like partition_point for doing binary search.

2. Containers from Boost.Container --- this includes a multitude of containers that are not in the C++ standard yet. My personal favourites among these containers are the flat_map and flat_set containers, which are much better implementations for the corresponding associative data structures than the STL ones, and small_vector, which does similar optimizations as the basic_string STL container, but has less stringent conditions on the type of things it can contain.

3. Better bitsets using the dynamic_bitset library --- there was a recent post about dynamic bitsets in Python, but I mentioned a way of getting there using a hack with C++ STL bitsets. However, dynamic bitsets are supported in Boost. In fact, the Boost implementation also exposes functions like find_first, find_next, range set, range flip and so on.

4. Graph algorithms from the Boost Graph Library --- it contains practically every useful graph algorithm that we encounter in competitive programming.

5. Different kinds of heaps with Boost.Heap --- this contains multiple types of heaps with a lot of useful specialized functions. Ever wanted to try out a Fibonacci heap? Or just any heap with decrease-min or deletion operations? This library will cater to all your needs.

6. Interval handling using Boost.Icl --- often we want to handle ranges of integers in competitive programming problems. This library gives us ready-made data structures to solve such problems, without having to think about corner cases that arise with interval sets. This solution is a prime example that would be much easier to implement with this library.

7. Intrusive containers using Boost.Intrusive --- there are times when we want to implement a list manually, with some additional information inside the node. For example, there is an implementation of adjacency lists that is quite popular in China, which makes an array of nodes, and inside those nodes, it stores pointers/index of next/previous edges. Doing that using an std::list would be quite painful, and there is a reasonable compromise using intrusive lists. In general, intrusive containers tend to be faster, so if you like constant optimization, this library is pretty nice to know about.

8. Boost.Math --- this contains a ton of useful math features. Unfortunately, the polynomial library they provide doesn't have fast operations (polynomial multiplication is quadratic for example), but the rest of the functionality is pretty good. It has things like continued fractions, root finding and quaternions, all of which I have seen in competitive programming contests.

9. BigInt using Boost.Multiprecision --- self-explanatory.

10. Linear algebra using Boost uBLAS --- this is a linear algebra library that has pretty much all the functionality one would ever need on a competitive programming problem. However, this library is quite old, and it is usually recommended to use other libraries just for that reason (though I don't find this to be off-putting). The one thing you need to squeeze out performance is to define the macro BOOST_UBLAS_NDEBUG.

Hopefully this was enough to convince some people that Boost is quite a handy library, that might be worth putting effort into learning, and that it convinces MikeMirzayanov to add it on Codeforces.

@online{boost-in-competitive-programming-2023,
  author    = {nor},
  title     = {The Boost C++ library in competitive programming},
  year      = {2023},
  month     = {10},
  day       = {28},
  url       = {https://nor-blog.pages.dev/posts/2023-10-28-boost-in-competitive-programming},
}

Negative indexing with end

Have you ever found yourself using a vector like a stack just because you have to also access the last few positions, or writing a sliding window code using a deque (where the size might be variable, but you want to access an element at some offset from the end)?

Chances are that you have written code like this:

while (stk.size() >= 3 && stk[stk.size() - 2] + stk[stk.size() - 1] > stk[stk.size() - 3]) {
  stk.pop_back();
}

A cleaner way of writing the same thing is this:

while (stk.size() >= 3 && end(stk)[-2] + end(stk)[-1] > end(stk)[-3]) {
  stk.pop_back();
}

This trick works not just for end, but for any iterator, provided that (roughly) there is no undefined behaviour like out of bounds accesses.

This can be done only with iterators which provide random access. For example, iterators for vectors but not for sets.

Free functions like len and str

Python's len and str come in handy a lot of times, and they're convenient to use because they're free functions (that is, not member functions).

Fortunately, C++ has its own set of free functions that are quite helpful:

1. size(v): It returns the unsigned size of $v$, and does the same thing as v.size() That is, its numerical value is the size of $v$, and type is some unspecified unsigned type (aliased to size_t). This also works for arrays (but not raw pointers).
2. ssize(v): It returns the signed size of $v$. This is quite useful, because it prevents bugs like a.size() - 1 on empty a. It doesn't have a member function analogue, though. This also works for arrays (but not raw pointers). If you use sz macros, you can safely remove them from your code!
3. begin(v), end(v), rbegin(v), rend(v): They do the same thing as what their corresponding member functions do. These also work for arrays (but not raw pointers).
4. empty(v): This checks if $v$ is empty or not. Analogous to v.empty()
5. data(v): This returns a pointer to the block of data where it works.
6. to_string(x): This returns the string representation of a datatype. They're only defined for things like int and double though.

Variable declaration in loops/conditions

If you have used range-based for loops, you might have noticed that there is no support for indexing by default. So people usually either just switch to index based loop, or do the following:

int i = -1;
for (auto x : a) {
  i++;
  // do something
}
// or
{
  int i = -1;
  for (auto x : a) {
    i++;
    // do something
  }
}

However, it either pollutes the parent scope with the variable i and makes things buggy, or just looks ugly. C++20 has the following feature that makes it cleaner:

for (int i = -1; auto x : a) {
  i++;
  // do something
}

Similarly, if there is an object such that you only have to inspect its properties just once and it becomes useless later on, you can construct it in the init part of the if condition, like this:

if (auto x = construct_object(); x.good() && !x.bad()) {
  // do something
}

Unpacking structs

A lot of people write code that looks like this:

std::vector<std::tuple<int, char, std::string>> a;
// populate a
for (int i = 0; i < (int)a.size(); ++i) {
  int x = std::get<0>(a[i]);
  char y = std::get<1>(a[i]);
  std::string z = std::get<2>(a[i]);
}
// or
for (auto& A : a) {
  int x = std::get<0>(A);
  char y = std::get<1>(A);
  std::string z = std::get<2>(A);
}
// or
for (auto& A : a) {
  int x; char y; std::string z;
  std::tie(x, y, z) = A;
}

A cleaner and more consistent way of writing this can be:

for (auto [x, y, z] : a) {
}
// or
for (auto& A : a) {
  auto [x, y, z] = A;
}

If you want references instead of copies stored in x, y, z, then you can do this:

for (auto& [x, y, z] : a) {
}
// or
for (auto& A : a) {
  auto& [x, y, z] = A;
}

Note that this is not limited to for loops, or even to just tuples, and you can use this sort of unpacking (structured binding) for most structs (in particular, custom structs you make, or std::pair). In fact, if you have std::array<int, 3>, then this unpacking will give you its contents in three different variables.

Some more utilities

There are some lesser known functionalities that C++20 introduced, like starts_with and ends_with on strings. Some of the more useful ones can be found here.

Notably, there is also support for binary searching like we do in competitive programming, and the relevant information can be found in the language specific section of this post.

You can also print a number in binary, analogously to what you can do in Python. This can be done by constructing a bitset out of the integer and converting it to a string, or just by printing std::format("{:b}", a) (which is unfortunately not on CF yet).

emplace_back, emplace_front and emplace

Seriously, stop using a.push_back(make_pair(1, 2)) and a.push_back(make_tuple(1, 2, 3)) and even a.push_back({1, 2, 3}), and start using a.emplace_back(1, 2) instead.

The only reasonably common place this doesn't work is when you have a container that stores std::array, so emplace_back doesn't work; in that case a.push_back({1, 2, 3}) is fine.

The other variants: emplace_front and emplace do the same thing for their other counterparts (for example, in a deque, queue or priority_queue).

Lambdas

Lambdas in C++ are in fact cleaner and more intuitive (with more features) than in Python. Compared to both Python lambdas (being able to have more than 1 line of code) and local functions (having mutable states more intuitively and capturing parameters from an ancestor scope), in fact. This is because you can capture stuff more explicitly, have mutable state, can pass them as function objects, and even implement recursion using generic lambdas, though C++23 will have a feature called deducing this which will make a lot of things much simpler.

They can be passed around to almost all algorithms in the STL algorithms library, which is part of the reason why the STL is so powerful and generic.

They can also be used to make certain functions local, and avoid polluting the global namespace with function definitions. One more thing about them is that they are constexpr by default, which is not true for traditional functions.

Vector-like data structure without iterator invalidation

You probably know what we're coming to at this point: std::deque. It is essentially std::vector (without $O(1)$ move guarantees but whatever), but with no iterator invalidation on resizing/adding elements.

That is why it is ideal in a very important setting:

• Making buffers of elements (so that we can use pointers to elements without worrying about what happens when the buffer is resized).

No more Python laughing in our face about having to worry about iterator invalidation!

Python style ranges and even more flexible range manipulation

Using temporary container in for loop

Suppose you want to do something for multiple arguments, but they aren't indices. Most people would either duplicate code, or do something like this:

vector<char> a{'L', 'R', 'D', 'U'};
for (auto x : a) { /* do something */ }

But this has a disadvantage: it needs more characters and also makes it more error-prone to use vectors. Instead of this, you can do this:

for (auto x : {'L', 'R', 'D', 'U'}) { /* do something */ }

or even

for (auto x : "LRDU"s) { /* do something */ }

Note that the s at the end makes it a string literal which is why it works, and const char* doesn't work because there is a \0 at the end of the literal. This can still allocate on the heap (not in this case, only for big strings due to SSO).

In case you explicitly want an allocation with a vector for some reason, you can use

for (auto x : std::vector{'L', 'R', 'D', 'U'})

or

for (auto x : std::vector<char>{'L', 'R', 'D', 'U'})

Ranges

C++20 has a feature called ranges, that allows you to do manipulations on, well, ranges.

Let's think about how to implement this: For integers between 1 to 5, multiply them by 2, and print the last 3 elements in reversed order.

#include <bits/stdc++.h>

int main() {
  std::vector<int> a{1, 2, 3, 4, 5};
  for (auto& x : a) x *= 2;
  for (int i = 0; i < 3; ++i) std::cout << a[(int)a.size() - i - 1] << '\n';
}

However, this is prone to having bugs (what about out of bounds errors in some other scenario?), and doesn't look intuitive at all.

Now consider this:

#include <bits/stdc++.h>

namespace R = std::ranges;
namespace V = std::ranges::views;

int main() {
    for (auto x : V::iota(1, 6) | V::transform([](int x) { return x * 2; }) | V::reverse | V::take(3))
        std::cout << x << '\n';
}

Here the intent is pretty clear. You take integers in $[1, 6)$, multiply them by 2, reverse them, and take the first 3. Now in this resulting range of numbers, you print each of them.

So let's see what happens here. The | operator is defined for ranges and an operation on ranges that returns a range. For example, V::transform(range, lambda) gives a range where every element is transformed, and doing range | V::transform(lambda) does the same thing. In fact, for a lot of cases, this isn't stored in memory at all (and operations are done while iterating on the fly), unless you have things like reversing a range.

One thing that you can finally do is split a string with delimiters in a nice way (which used to be a major point of ridicule directed towards C++ from a lot of Python users). This is as simple as using a split view in the ranges library. For more information, see this. Here's an example taken verbatim from the cppreference page:

#include <iomanip>
#include <iostream>
#include <ranges>
#include <string_view>

int main() {
    constexpr std::string_view words{"Hello^_^C++^_^20^_^!"};
    constexpr std::string_view delim{"^_^"};
    for (const auto word : std::views::split(words, delim))
        std::cout << std::quoted(std::string_view{word.begin(), word.end()}) << ' ';
}

A more common example can be like this:

#include <bits/stdc++.h>

namespace R = std::ranges;
namespace V = std::ranges::views;

int main() {
    std::cin.tie(nullptr)->sync_with_stdio(false);
    std::string s(1000000, '0');
    for (int i = 0; i < 1000000 / 2; ++i) s[i * 2] = '1';
    for (const auto word : V::split(s, '1'))
        std::cout << std::string_view{begin(word), end(word)} << ' ';
}

Some ranges functionality is as follows:

• converting to and from a range: conversion to a range is implicit for most STL containers. If r is a range, then for most STL containers, like std::vector, you can do something like std::vector<int> a(r.begin(), r.end()). C++23 has a feature R::to<ContainerType>(range) that will construct a container out of a range, and you could even do range | R::to<ContainerType>().
• iota: This works similarly to Python's range() but without the stride.
• reverse: This works similarly to Python's reversed()
• take: This takes the first $n$ elements of a range (unless you run out of elements by then)
• drop: This takes everything but the first $n$ elements of a range (unless you run out of elements by then)
• counted: This takes $n$ elements of a range starting from an iterator.
• keys, values: keys takes a range whose elements are pair-like and returns a range of their first elements (so if we have (key, value) pairs, it will return keys), similar to .keys() in Python. Similarly, values returns a range of the values.
• elements: if we have a range of tuple-like elements, this takes the $n$-th members of each of these tuples (where $N$ is a compile-time constant).
• all: though type conversions from containers to ranges are usually implicit, it takes a container and takes everything in that container.
• Some upcoming C++23 features that will make it even more convenient to use ranges: to, zip, slide, stride, repeat, adjacent, pairwise, cartesian_product.

Note that this is not the only thing you can do with ranges. In fact, with almost all possible algorithms that you can find in the algorithms library that use a begin and an end iterator (like std::sort or std::partial_sum or std::all_of), you can find a ranges version here, where you can just pass the range/container name instead of the begin and end iterators you usually pass.

By the way, if you don't want to wait for C++23, you can use some of the functionality from this code, which I used to use a couple of years ago when C++20 was not a thing.

template <typename T>
struct iterable;
template <typename T>
struct iterable<T&> {
    using type = T&;
};
template <typename T>
struct iterable<T&&> {
    using type = T;
};
template <typename T, std::size_t N>
struct iterable<T (&&)[N]> {
    using type = typename T::unsupported;
};
template <typename T>
struct iterator_from_iterable {
    using iterable = typename std::remove_reference<T>::type&;
    using type = decltype(std::begin(std::declval<iterable>()));
};
template <typename T>
struct iterable_traits {
    using raw_iterable = T;
    using raw_iterator = typename iterator_from_iterable<raw_iterable>::type;
    using wrapped_iterable = typename iterable<T>::type;
    using deref_value_type = decltype(*std::declval<raw_iterator>());
};

template <typename T>
struct Range {
   private:
    const T l, r, skip;

   public:
    struct It : public std::iterator<std::forward_iterator_tag, T> {
        T i;
        const T skip;
        explicit It(T _i, T _skip) : i(_i), skip(_skip) {}
        It& operator++() { return i += skip, *this; }
        const It& operator++(int) {
            auto temp = *this;
            return operator++(), temp;
        }
        T operator*() const { return i; }
        bool operator!=(const It& it) const { return (skip >= 0) ? (i < *it) : (i > *it); }
        bool operator==(const It& it) const { return (skip >= 0) ? (i >= *it) : (i <= *it); }
    };
    using iterator = It;
    using value_type = T;
    Range(T _l, T _r, T _skip = 1) : l(_l), r(_r), skip(_skip) {
#ifdef DEBUG
        assert(skip != 0);
#endif
    }
    Range(T n) : Range(T(0), n, T(1)) {}
    It begin() const {
        return It(l, skip);
    }
    It end() const {
        return It(r, skip);
    }
    It begin() {
        return It(l, skip);
    }
    It end() {
        return It(r, skip);
    }
};

template <typename... T>
struct zip {
   public:
    using value_type = std::tuple<typename iterable_traits<T>::deref_value_type...>;
    using wrapped_iterables = std::tuple<typename iterable_traits<T>::wrapped_iterable...>;
    using raw_iterators = std::tuple<typename iterable_traits<T>::raw_iterator...>;
    using sequence = std::index_sequence_for<T...>;
    struct It : public std::iterator<std::forward_iterator_tag, value_type> {
       public:
        explicit It(raw_iterators iterators) : iterators_(std::move(iterators)) {}
        bool operator==(const It& it) const { return any_eq(it, sequence()); }
        bool operator!=(const It& it) const { return !any_eq(it, sequence()); }
        value_type operator*() const { return deref(sequence()); }
        It& operator++() { return inc(sequence()), *this; }
        const It& operator++(int) {
            auto temp = *this;
            return operator++(), temp;
        }

       private:
        raw_iterators iterators_;
        template <std::size_t... I>
        bool any_eq(const It& it, std::index_sequence<I...>) const {
            return (... || (std::get<I>(iterators_) == std::get<I>(it.iterators_)));
        }
        template <std::size_t... I>
        value_type deref(std::index_sequence<I...>) const {
            return {(*std::get<I>(iterators_))...};
        }
        template <std::size_t... I>
        void inc(std::index_sequence<I...>) {
            (++std::get<I>(iterators_), ...);
        }
    };
    using iterator = It;
    explicit zip(T&&... iterables) : iterables_(std::forward<T>(iterables)...) {}
    It begin() { return begin_(sequence()); }
    It end() { return end_(sequence()); }
    It begin() const { return begin_(sequence()); }
    It end() const { return end_(sequence()); }

   private:
    wrapped_iterables iterables_;
    template <std::size_t... Int>
    iterator begin_(std::index_sequence<Int...>) {
        return iterator(std::tuple(std::begin(std::get<Int>(iterables_))...));
    }
    template <std::size_t... Int>
    iterator end_(std::index_sequence<Int...>) {
        return iterator(std::tuple(std::end(std::get<Int>(iterables_))...));
    }
};

template <typename... T>
zip(T&&...) -> zip<T&&...>;

template <typename T>
struct enumerate {
   public:
    using size_type = typename std::make_signed<std::size_t>::type;
    using wrapped_iterable = typename iterable_traits<T>::wrapped_iterable;
    using raw_iterator = typename iterable_traits<T>::raw_iterator;
    using value_type = std::pair<size_type, typename iterable_traits<T>::deref_value_type>;
    struct It : public std::iterator<std::forward_iterator_tag, value_type> {
        raw_iterator iter_;
        size_type start_;

       public:
        It(raw_iterator it, size_type start) : iter_(it), start_(start) {}
        bool operator==(const It& it) const { return iter_ == it.iter_; }
        bool operator!=(const It& it) const { return iter_ != it.iter_; }
        It& operator++() { return ++iter_, ++start_, *this; }
        const It operator++(int) {
            auto temp = *this;
            return operator++(), temp;
        }
        value_type operator*() const { return {start_, *iter_}; }
    };
    using iterator = It;
    explicit enumerate(T&& iterable, size_type start = 0) : iterable_(std::forward<T>(iterable)), start_(start) {}
    It begin() { return It(std::begin(iterable_), start_); }
    It end() { return It(std::end(iterable_), 0); }
    It begin() const { return It(std::begin(iterable_), start_); }
    It end() const { return It(std::end(iterable_), 0); }

   private:
    wrapped_iterable iterable_;
    size_type start_;
};

template <typename T>
enumerate(T&&) -> enumerate<T&&>;
template <typename T, typename Index>
enumerate(T&&, Index) -> enumerate<T&&>;