Nano-introduction to Linking

We start with source files. In the first phase, the compiler translates them into object files. An object file is nothing but a container for sections. Two canonical examples for sections are as .text which contains machine code and .data which contains program data.

In the second phase, the linker - the first thing it does is, it pulls together the identically named sections and concatenates them into one larger section. The second thing it does, is it reorders the sections. So, sections with similar required run-time permissions are adjacent on disk.

In the final stage, the loader takes these adjacent chunks called segments and maps them to memory on page-aligned boundaries. After this mapping, the loader adjusts the page permissions accordingly.

Now, code typically does lots of function calls. The simplest case is that of from the binary into itself. But, that is not the general case. In general, the process can map shared libraries into its address space and perform calls into functions which are implemented in the shared library. The shared library itself can perform calls into functions implemented in yet other shared libraries. Arguably, the most important job of both the linker and loader is to properly wire these calls. How would might a wiring look like?

Say, we have a .code section that calls the function foo(), which is implemented in another binary. The .code section itself does not contain the string foo, it contains a call 0x0000 instruction into an address yet unknown at link time. So, the .code section contains a placeholder - a string of 0s. In addition, the linker generates another section called .reloc for relocation. On Windows, these are sometimes called fixups. A .reloc section is essentially a small TODO item for the loader. The linker says, “Dear loader, please find the function foo, when you do overwrite this placeholder with the address you found.”. This relocation does happen in practice, but it is generally frowned upon, for two reasons. First, modifying the .code section makes the .code section unshareable between processes and second this form of relocation needs to be done once per call site, not once per function, which can amount to a large difference if you have tens of thousands of calls into the same function e.g. a game engine with calls to the math function sqrt().

The more typical scheme is to route all calls to the same function through an indirect call into a single placeholder. In this scheme, when the loader reads the .reloc section, it knows it needs to overwrite just a single slot with the function foo()’s address and not all the call sites. This design trades a little bit of run-time performance for a lot of load-time savings. There is an entire section of such placeholders. On win64, it is called the IAT (Import Address Table). In Linux, this is a rough approximation for a section known as the GOT(Global Offset Table). Note already, that this design means that cross-binary calls are indirect. They carry the same overhead as virtual functions do. And this is not the full truth, it is just the first step in our journey towards it.

Windows Binary (.exe / .dll)
+------------------------------------------------------------------------------+
|  .idata section                                                              |
|  +--------------------------+                                                |
|  |     Directory table      |                                                |
|  |                          |                                                |
|  |  +--------------------+  |   ILT (symbol names)    IAT (addresses)        |
|  |  |  Entry: lib1.dll   |--+--> +--------------+    +--------------+        |
|  |  |  name / ILT / IAT  |  |    |  f1          |    |  <- addr(f1) |        |
|  |  +--------------------+  | +->|  f2          |    |  <- addr(f2) |        |
|  |           |              | |  |  f3          |    |  <- addr(f3) |        |
|  |           +--------------+-+  +--------------+    +--------------+        |
|  |                          |              ^                   ^             |
|  |  +--------------------+  |   ILT        |        IAT        |             |
|  |  |  Entry: lib2.dll   |--+--> +--------------+    +--------------+        |
|  |  |  name / ILT / IAT  |  |    |  g1          |    |  <- addr(g1) |        |
|  |  +--------------------+  | +->|  g2          |    |  <- addr(g2) |        |
|  |           |              | |  |  g3          |    |  <- addr(g3) |        |
|  |           +--------------+-+  +--------------+    +--------------+        |
|  +--------------------------+              |                   |             |
|                                            +---------+---------+             |
+------------------------------------------------------------------------------+

readelf -d $(which ls) | grep NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libcap.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

readelf -W --syms $(which ls)

Symbol table .dynsym contains 132 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __ctype_toupper_loc@GLIBC_2.3 (2)
     2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND getenv@GLIBC_2.2.5 (3)
     3: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND cap_to_text
     4: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND sigprocmask@GLIBC_2.2.5 (3)
     5: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __snprintf_chk@GLIBC_2.3.4 (4)
     6: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND raise@GLIBC_2.2.5 (3)
     7: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND free@GLIBC_2.2.5 (3)
     8: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __vfprintf_chk@GLIBC_2.3.4 (4)
     9: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.34 (5)
    10: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __mempcpy_chk@GLIBC_2.3.4 (4)
    11: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND abort@GLIBC_2.2.5 (3)
    12: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __errno_location@GLIBC_2.2.5 (3)
    13: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND strncmp@GLIBC_2.2.5 (3)
    14: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_deregisterTMCloneTable
    15: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND localtime_r@GLIBC_2.2.5 (3)
    16: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _exit@GLIBC_2.2.5 (3)
    17: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __fpending@GLIBC_2.2.5 (3)
    18: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND flistxattr@GLIBC_2.3 (2)
    19: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND isatty@GLIBC_2.2.5 (3)
    20: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND sigaction@GLIBC_2.2.5 (3)
    21: 0000000000000000     0 FUNC    GLOBAL DEFAU

Linux Binary (ELF)
 +------------------------------------------------------------------------------+
|                                                                              |
|  .code section                                                               |
|  +------------------------------------------------------------------------+  |
|  |  .text   (executable instructions)                                     |  |
|  |  .rodata (read-only data, string literals, ...)                        |  |
|  |  PLT     (per-symbol call stubs -> resolved via GOT at runtime)        |  |
|  +------------------------------------------------------------------------+  |
|                                                                              |
|  .data section                                                               |
|  +------------------------------------------------------------------------+  |
|  |  .data   (initialised global/static variables)                         |  |
|  |  .bss    (uninitialised global/static variables)                       |  |
|  |  GOT     (per-symbol address slots, patched by loader at runtime)      |  |
|  +------------------------------------------------------------------------+  |
|                                                                              |
|  .dynamic section                                                            |
|  +------------------------------------------------------------------------+  |
|  |  NEEDED  libcap.so.2                                                   |  |
|  |  NEEDED  libc.so.6                                                     |  |
|  |  (library names only -- no symbol information)                         |  |
|  +------------------------------------------------------------------------+  |
|                                                                              |
|  .dynsym section                                                             |
|  +------------------------------------------------------------------------+  |
|  |  Ndx  Name                         Bind    Source                      |  |
|  |  ---  ---------------------------  ------  --------------------------  |  |
|  |  UND  __ctype_toupper_loc          GLOBAL  GLIBC_2.3                   |  |
|  |  UND  getenv                       GLOBAL  GLIBC_2.2.5                 |  |
|  |  UND  cap_to_text                  GLOBAL  libcap.so.2                 |  |
|  |  UND  sigprocmask                  GLOBAL  GLIBC_2.2.5                 |  |
|  |  UND  free                         GLOBAL  GLIBC_2.2.5                 |  |
|  |  UND  abort                        GLOBAL  GLIBC_2.2.5                 |  |
|  |   :   ...                                                              |  |
|  |   9   main                         GLOBAL  (defined in this binary)    |  |
|  |  10   some_exported_fn             GLOBAL  (defined in this binary)    |  |
|  |   :   ...                                                              |  |
|  +------------------------------------------------------------------------+  |
|                                                                              |
+------------------------------------------------------------------------------+

Interposition

Interposition is the ability of overriding a symbol in one binary from another. This is a cornerstone of the design of linux execution model. It is a fundamental ABI design pillar.

You might come across alleged motivation for this. There are some claims online that say, the ELF pioneers designed it this way, so dynamic shared libraries would mimic the behavior of earlier static libs. Supposedly, in static libraries, if several libraries implement the same symbol, then the first definition encountered is used and it shadows the later ones. However, that is not entirely true. It might be the case, but you might also get a linker error complaining about ODR violations. The exact behavior depends upon which members are extracted from the static archives.

A different conjectured motivation is that the canonical model in the minds of the ELF architects was the library libc. libc is beyond ubiquitous, it is universal. It is loaded by practically all applications and it is huge. Therefore, it is reasonable to anticipate that users might want to override some of its implementations. Therefore, this capability was baked into the architecture. But this is guesswork. We have internal knowledge about the motivation.

So, we have discussed one facility that enables interposition - that is the separation of library names from list of symbols to consume. Let’s discuss another - library search order.

Library Search Order

The library search order in Linux is breadth-first search. What this means is, suppose we have an executable which loads the dynamic libraries lib1 and lib2 and these internally load the libraries lib3, lib4 and lib5. Furthermore say that, lib5 wants to use the symbol foo. The order in which the binaries would be searched by the loader for the symbol foo is the first the exe (the executable), then lib1, lib2, then lib3 and lib4 and only finally lib5, even if lib5 implements foo. All the other binaries get an opportunity to interpose foo before it is sought in lib5 itself.

                    ┌───────────────┐
                    │      exe      │
                    └───────┬───────┘
            ┌───────────────┴───────────────┐
            │                               │
    ┌───────┴───────┐               ┌───────┴───────┐
    │     lib1      │               │     lib2      │
    └───────┬───────┘               └───────┬───────┘
    ┌───────┴───────┐                       │
    │               │                       │
┌───┴───────┐ ┌─────┴─────┐         ┌───────┴───────┐
│   lib3    │ │   lib4    │         │     lib5      │
└───────────┘ └───────────┘         │  defines foo  │
                                    └───────────────┘

In particular, the executable is consulte before the current library. This is the default behavior, it can be adjusted. The most direct way is linking lib5 with the linker switch -Bsymbolic. -Bsymbolic tells the linker, that when resolving symbols in lib5, searchn in lib5 before the usual breadth first order.

                    ┌───────────────┐
                    │      exe      │ 
                    └───────┬───────┘
                    ┌───────┴───────┐
                    │   LD_PRELOAD  │  
                    └───────┬───────┘
            ┌───────────────┴───────────────┐
            │                               │
    ┌───────┴───────┐               ┌───────┴───────┐
    │     lib1      │               │     lib2      │
    └───────┬───────┘               └───────┬───────┘
    ┌───────┴───────┐                       │
    │               │                       │
┌───┴───────┐ ┌─────┴─────┐         ┌───────┴───────┐
│   lib3    │ │   lib4    │         │     lib5      │
└───────────┘ └───────────┘         │  defines foo  │
                                    └───────────────┘

                    ┌─────────────────────┐
                    │          exe        │
                    | operator new(size_t)|
                    └───────────┬─────────┘
            ┌───────────────────┴────────────────────┐
            │                                        │
    ┌───────┴───────┐                   ┌────────────┴─────────┐
    │     glibc     │                   │       libc++         │
    |               |                   | operator new(size_t) |
    +---------------+                   +----------------------+

Symbol Resolution Time

Let’s discuss another mechanism that supports interposition. The default behavior is governed by the default switch --allow-shlib-undefined. If we have the below tree of dependencies and suppose lib5 wishes to import the symbol foo and the exe wishes to import the symbol bar. The resolution for the exe symbols is checked at link-time. The linker would refuse to link the executable, if it cannot resolve the symbol bar.

That is not true of the libraries. The linker would very happily agree to link lib5, even if it cannot see foo. As far as the linker is concerned, the implementation of foo might lie in the executable, where it has no chance of discovering it.

                    ┌───────────────┐
                    │      exe      │---(bar    Resolution checked 
                    └───────┬───────┘           at link time
                    ┌───────┴───────┐
                    │   LD_PRELOAD  │  
                    └───────┬───────┘
            ┌───────────────┴───────────────┐
            │                               │
    ┌───────┴───────┐               ┌───────┴───────┐
    │     lib1      │               │     lib2      │
    └───────┬───────┘               └───────┬───────┘
    ┌───────┴───────┐                       │
    │               │                       │
┌───┴───────┐ ┌─────┴─────┐         ┌───────┴───────┐
│   lib3    │ │   lib4    │         │     lib5      │---(foo  Resolution NOT
└───────────┘ └───────────┘         └───────────────┘        checked at link time

This behavior can be controlled with some switches. The easiest would be linking the executable with a --no-allow-shlib-undefined on the exe.

C++ Impliciation : How to form a process-wide singleton?

Let’s discuss a developer facing implication of this. Can we have a process-wide singleton? By singleton, I mean the Meyers singleton design pattern - a single object which has a unique instance which is usable by all the code in the process, from all binaries.

In Windows, the usual singleton design pattern would create a per-binary singleton.

C++ Compiler

A compiler translates C++ source code into low-level machine code (targeted to a specific architecture, for example x86_64, ARM etc). More specifically, each source file is translated into an object file, that contains machine code. Object files are little pieces of machine code, that can be linked together.

gcc/g++, clang/clang++, msvc are examples of major compilers.

Build system

While a hobby project starts out simple enough that you can build it just using a compiler, as your system grows more complex, it can quickly become unwieldy. Sure enough, you can write a script, but you begin spending almost as much time working on build scripts as on real code. To make sure you aren’t accidentally relying on stale libraries, you have your build script build every dependency in order every time you run it. Very quickly, you run into a classic problem of scale.

Here is crash-course on build systems. A build system automates the compilation and linking of the source code in a code base into a library or executable. At a high-level build systems are tools or libraries that provide a way to define and execute a series of transformations from input data to output data that are memoized by caching them in an object store.

Transformations are called steps or rules and define how to execute a task that generates zero or more outputs from one or more inputs. A rule is usually a unit of caching; i.e. cache points are the outputs of a rule, and cache invalidations must happen on the inputs of a rule. Rules are the like the edges of a graph, they can have dependencies on previous outputs, forming a dependency graph. The dependency graph must be a DAG.

Each invocation of the build tool is called a build. A full build or a clean build occurs when the cache is empty and all transformations are executed as a batch job. An incremental build occurs when the cache is partially full but some outputs are outdated and need to be rebuild. Deleting the cache is called cleaning.

A build is correct or sound if all possible incremental builds have the same result as a full build.

A build system without caching is called a task runner or batch compiler. Some examples of build systems are: ninja, GNU make, docker build, rustc. Some examples of task runners are: just, shell scripts.

In the context of builds, build files contain rule definitions, input and output declarations.

Toolchain

All of the above programming tools combined together form a toolchain (a suite of tools used in a serial manner). Examples would be the GNU toolchain, the LLVM project.

Meta-build system

Usually, a meta-build system runs a configuration step and requires another tool such as ninja for the actual build step. The meta-build system discovers the rules that need to be executed (often through a programmatic way to describe dependencies or through file globbing), and then serializes (persists) these rules into an action graph, which can be stored either in memory or on disk. On-disk serialized action graphs are themselves build files, in the sense, you can write them by hand but you wouldn’t want to.

If you’ve ever used CMake, you know that there are two steps involved : a configure step (cmake -b build-dir) and a build step cmake --build -S source-dir, An action graph is a serialization of all the build steps, with the ability to regenerate the graph by rerunning the configure step.

Some examples of meta-build systems are CMake, meson and autotools.

Not all meta-build systems serialize their action graph. bazel and buck2 run persistent servers that store it in memory and allow querying it, but never serialize it to the disk. For large graphs, this requires a lot of memory.

Language Servers

Most modern IDEs provide programnmers with sophisticated features like code completion, hover tooltips, finding symbols, jump-to-definitions, syntax highlighting etc. Language services used to be tightly embedded within the editor or IDE. Assume that there are code editors and language servers, we would need to write (-times-) plugins to provide Visual Studio like sophisticated features for all programming languages on all code-editors.

The Language Server Protocol(LSP) reduces an problem to an problem. LSP allows language communities to concentrate their efforts on building a single, high performing language server that can provide code completion, hover tooltips, jump-to-definition, find-references, while editor and client communities can concentrate on a building a single, intuitive, high-performing extension that can communicate with any language server.

The LSP is a protocol for sending messages in a JSON-RPC format that allows the development tool to communicate with any language server. And a single language server can be reused in multiple development tools.

Debugger

Debuggers are the most valuable tool in any developer’s kit. Debuggers allow you to step through the source code, inspect the values of variables, set breakpoints and much more.

Debug Adapter Protocol(DAP)

The Debug Adapter Protocol(DAP) is an abstract protcol that allows any development tool to communicate with any debug-adapter.

Setup

This is my development environment setup on Arch.

• Compiler: clang++
• Debugger: lldb
• Language Server: clangd
• Meta-build system: CMake
• Build system: ninja
• Integrated Development Environment: Visual Studio Code
• C++ code linter: clang-tidy
• Source code formatter: clang-format
• Source code documentation generator: doxygen
• Software package distribution management: CPack
• VCS(Version Control System): Git

LLVM_VER="19"
GCC_VER="16" 

PACKAGES=(
    ninja-build valgrind htop gcc-$GCC_VER g++-$GCC_VER
    clang-$LLVM_VER clangd-$LLVM_VER llvm-$LLVM_VER-dev
    clang-format-$LLVM_VER clang-tidy-$LLVM_VER
    libc++-$LLVM_VER-dev libc++abi-$LLVM_VER
    libpolly-$LLVM_VER-dev lld-$LLVM_VER lldb-$LLVM_VER
    cmake curl jq htop build-essential ripgrep snapd
    texlive-latex-base latexmk
)

sudo apt install "${PACMAN_PACKAGES[@]}"

#!/usr/bin/env bash
set -euo pipefail

# --- Official repo packages (pacman) ---
PACMAN_PACKAGES=(
  # LLVM / Clang toolchain (versioned slot from official repos)
  llvm
  clang          # clang++, clangd, clang-format, clang-tidy all bundled here
  libc++

  # GCC toolchain
  gcc            # includes g++

  # Build tools
  cmake ninja
  make           # equivalent of build-essential's make
  binutils       # equivalent of build-essential's binutils
  autoconf
  automake

  # Debugger / profiler
  lld lldb valgrind

  # Utilities
  curl jq htop ripgrep git

  # LaTeX
  texlive-basic       # equivalent of texlive-latex-base
  texlive-binextra    # includes latexmk
)

sudo pacman -Syu --needed --noconfirm "${PACMAN_PACKAGES[@]}"

{
    "recommendations": [
        "llvm-vs-code-extensions.vscode-clangd",
        "ms-vscode.cpptools-extension-pack",
        "ms-vscode-remote.vscode-remote-extensionpack",
        "cs128.cs128-clang-tidy",
        "donjayamanne.githistory",
        "josetr.cmake-language-support-vscode",
        "mhutchie.git-graph",
        "ms-vscode.cmake-tools",
        "vadimcn.vscode-lldb",
        "waderyan.gitblame",
        "xaver.clang-format",
        "github.vscode-pull-request-github",
        "ms-vsliveshare.vsliveshare"
    ]
}

Variant visitation

// Traditional visitation example - one variant
struct printer{
    void operator()(int){ std::cout << "int" << "\n"; }
    void operator()(float){ std::cout << "float" << "\n"; }
    void operator()(double){ std::cout << "double" << "\n"; }
};

using my_variant = std::variant<int, float, double>;
my_variant v0{ 20.0f };

std::visit(printer{}, v0);

struct circle{ double radius_; };
struct box{ 
    double width_; 
    double height_;
    double depth;
};

struct collision_resolver{
    void operator()(circle, circle){ /*...*/ }
    void operator()(circle, box){ /*...*/ }
    void operator()(box, circle){ /*...*/ }
    void operator()(box, box){ /*...*/ }
};

using my_variant = std::variant<circle, box>;
my_variant v0{circle{}};
my_variant v1{box{}};

std::visit(collision_resolver{}, v0, v1);

Building helper functions needed for std::visit

Under the hood std::visit must invoke the right candidate for the currently active alternatives from the function overload set. We start with the simplest case of variants. The central idea is to maintain a single array of function pointers. Each entry in the function pointer table has the shape [](Visitor visitor, Variant0 v0, Variant1 v1). For concreteness, assume that both variants v0 and v1 offer a choice between types:

using Variant0 = std::variant<int, float>;
using Variant1 = std::variant<int, float>;

It is possible to have distinguishable behaviors(overloads), when a visitor visits these variants. So, we build an array of size .

The std::visit implementation should automatically invoke the correct function overload based on the currently active types in v0 and v1. Before we proceed, let us fix some terminology first. Suppose a variant v allows a choice amongst types:

// Pseudo-code
std::variant<T0, T1, ..., Tn> v;

In the case of 2 variants v0 and v1 offering a choice amongst and alternative types respectively, we have a total of distinguishgable choices. For example, consider the case of v0 offer a choice of types and v1 offering a choice of types. Each choice is a distinct entry in the 2d-table, and we have a total of distinct choices. We will have candidates in our function overload set. We can assign a multi-index <i,j> to the function overload [](Ti, Tj){ /*...*/ }.

We can convert this 2d-table to a 1d-table.

Thus, the pointer to the function [](Ti, Tj){ /*...*/} with multi-index <i,j> is mapped to 4i + j 1d-index in a 1d-table.

In the case of 3 variants v0, v1 and v2 offering a choice amongst , and alternative types respectively, we have a total of distinguishable choices. We will have candidates in our function overload set. We can assign a multi-index <i,j,k> to the function overload [](Ti, Tj, Tk){ /*...*/ }.

where each entry <i,j,k> expands over . The full set of multi-indices and their 1D mappings is:

Thus, the pointer to the function [](Ti, Tj, Tk){ /*...*/} with multi-index <i,j,k> is mapped to the 1D-index .

We shall code up two helper functions to_1d_index<3,4,5>(size_t, size_t, size_t) and from_1d_index<3,4,5>(size_t) to convert a multi-index to a 1d-index and back.

namespace dev::tools{
    template<std::size_t... Dimensions>
    constexpr auto build_coeffs_array(){
        constexpr std::array<std::size_t, sizeof...(Dimensions)> dimensions { Dimensions... };
        constexpr std::size_t coeffs_size = sizeof...(Dimensions);
        std::array<std::size_t, coeffs_size> coeffs = {};
        
        for(std::size_t i{0}; i < coeffs_size; ++i)
            coeffs[i] = 1;

        for(std::size_t i{0}; i < coeffs_size - 1; ++i){
            // In step i, we need to populate all coeffs[j], j <= i
            for(std::size_t j{0}; j <= i; ++j){
                coeffs[j] *= dimensions[i+1];
            }
        }
        return coeffs;
    }
    /*
    coeff[0] = v1size * ... * v[n-1] size
    coeff[1] = v2size * .... *v[n-1] size
    ...
    coeff[n-2] = v[n-1] size
    coeff[n-1] = 1
    */
    template<std::size_t... Dimensions>
    std::size_t constexpr to_1d_index(auto... indices){
        constexpr std::array<std::size_t, sizeof...(Dimensions)> dimensions { Dimensions... };
        std::size_t coeffs_size = sizeof...(Dimensions);
        auto coeffs = build_coeffs_array<Dimensions...>();
                                                                                                       
        const std::array<size_t, sizeof...(indices)> indices_arr { indices... };
        //std::println("{}", indices_arr); 
        return std::inner_product(coeffs.begin(), coeffs.end(), indices_arr.begin(), 0); 
    }

    /*
    Suppose we have the dimensions <3, 5, 2> and the coordinates (1, 3, 1).
    (1, 3, 1) maps to the linear index 17. 
    */

    template<size_t N>
    constexpr auto build_coords_array(std::array<size_t,N> coeffs, size_t& initState){ 
        size_t state = initState;
        std::array<size_t, N> coords{};
        for(size_t i{0}; i < N; ++i){
            coords[i] = static_cast<size_t>(state / coeffs[i]);
            state -= coords[i] * coeffs[i];
        }
        return coords;
    }

    template<size_t... Dimensions>
    decltype(auto) constexpr from_1d_index(std::size_t n){
        constexpr std::size_t coords_arr_size = sizeof...(Dimensions);
        constexpr auto coeffs = build_coeffs_array<Dimensions...>();
        std::array<size_t, coords_arr_size> coords = build_coords_array(coeffs, n);
        return coords;
    }
}

Simpler case of and variants

I strongly recommend creating a simpler version first, maybe hardcoded with two or three variants. So you can get an idea of the actual shape before making it variadic. Otherwise you’d be facing both problems at once.

// Simple case of 2 variants
namespace dev{

    namespace example{

        struct Dummy{};
        template<typename T>
        using Wrapper = std::conditional_t<std::is_void_v<T>,Dummy,T>;


        template<typename Visitor, typename Variant0, typename Variant1>
        decltype(auto) visit(Visitor&& visitor, Variant0 v0, Variant1 v1){
            constexpr std::array<std::size_t, 2> dimensions = { std::variant_size_v<Variant0>, std::variant_size_v<Variant1> };
            constexpr std::size_t vtable_size = (std::variant_size_v<Variant0> * std::variant_size_v<Variant1>);
            using cases_t = std::string(*)(Visitor, Variant0, Variant1);
            static constexpr auto vtable {
                []<size_t... Indices>(std::index_sequence<Indices...>){
                    return std::array<cases_t,4>{
                        [](Visitor vis, Variant0 v0, Variant1 v1){ 
                            constexpr auto multi_idx = dev::tools::from_1d_index<2,2>(Indices);
                            return vis(std::get<multi_idx[0]>(v0), std::get<multi_idx[1]>(v1));
                    }... };
                    
                }(std::make_index_sequence<vtable_size>())
            };

            return vtable[dev::tools::to_1d_index<2,2>(v0.index(), v1.index())](visitor, v0, v1);
        }
    };
}

template<typename... Callables>
struct Visitor : Callables...{
    using Callables::operator()...;
};

void test_single_dispatch(){
    std::variant<int, float, double> v{0};
}

void test_double_dispatch(){
    std::variant<int, float> v1{0};
    std::variant<int, float> v2{3.14f};

    auto result = dev::example::visit(
        Visitor{
            [](int, int) -> std::string { return "(int, int)"; },
            [](int, float) -> std::string { return "(int, float)"; },
            [](float, int) -> std::string { return "(float, int)"; },
            [](float, float) -> std::string { return "(float, float)"; },
        },
        v1, v2
    );

    std::cout << "result = " << result << "\n";
}

Generalizing to a pack of variants.

The shape of a function inside the vtable_func array should be something like this:

[](Visitor&& vis, Variants&&... var) { /* ... */ }

Internally you would invoke vis with std::get<Is>(var)..., where Is... would be an index sequence or constexpr array of the desired indices.

namespace dev{
    template <typename Visitor, typename... Variants>
    decltype(auto) visit(Visitor &&visitor, Variants &&...vs) {
        constexpr std::size_t vtable_size = (std::variant_size_v<std::remove_cvref_t<Variants>> * ...);

        // Each entry in the vtable should have the shape [](Visitor visitor, Variants... vs){}
        using result_t = decltype(visitor(std::get<0>(vs)...));
        using cases_t = result_t(*)(Visitor, Variants...);

        static constexpr auto vtable{
            []<size_t... Indices>(std::index_sequence<Indices...>){
                constexpr std::array<std::size_t, sizeof...(Variants)> dimensions = { std::variant_size_v<std::remove_cvref_t<Variants>>... };
                constexpr std::size_t vtable_size = (std::variant_size_v<std::remove_cvref_t<Variants>> * ...);
                return std::array<cases_t, vtable_size>{
                    [](Visitor vis, Variants... vs) -> result_t{
                        constexpr auto multi_idx = dev::tools::from_1d_index<std::variant_size_v<std::remove_cvref_t<Variants>>...>(Indices);
                        return [&]<size_t... Is>(std::index_sequence<Is...>){
                            return vis((static_cast<std::variant_alternative_t<Is, std::remove_cvref_t<Variants>>>(std::get<multi_idx[Is]>(vs)))...);
                        }(std::make_index_sequence<sizeof...(Variants)>());
                    }...
                };
            }(std::make_index_sequence<vtable_size>())
        };

        auto i = dev::tools::to_1d_index<std::variant_size_v<std::remove_cvref_t<Variants>>...>(vs.index()...);
        return vtable[i](visitor, vs... );
    }
}

void test_multiple_dispatch(){
    std::variant<int, float, double> v1{0};
    std::variant<int, float, double> v2{3.14f};
    //std::variant<char, int, long, float, double> v3{'H'};

    auto result = dev::visit(
        Visitor{
            [](int, int) -> std::string { return "(int, int)"; },
            [](int, float) -> std::string { return "(int, float)"; },
            [](int, double) -> std::string { return "(int, double)"; },
            [](float, int) -> std::string { return "(float, int)"; }
        },
        v1, v2
    );

    std::cout << "result = " << result << "\n";
}

Compiler Explorer

Basic Visitor in C++

The only way to really understand how the Visitor pattern operates is to work through an example. Let’s start with a very simple one. First we need a class hierarchy:

#include <string>

struct Pet{
    virtual ~Pet(){}
    Pet(std::string_view color) : m_color{ color } {}
    const std::string& color() const{ return m_color; }

    private:
    const std::string m_color;
};

struct Cat : public Pet{
    public:
    Cat(std::string_view color) : Pet{ color } {}
};

struct Dog : public Pet{
    public:
    Dog(std::string_view color) : Pet{ color } {}
};

int main(){}

Compiler Explorer

In this hierarchy, we have the Pet base class and several derived classes for different pet animals. Now, we want to add some operations to our classes, suhc as feed the pet or play with the pet. The implementation depends on the type of the pet, so these would have to be virtual functions if added directly to each class. This is not a problem for such a simple class hierarchy, but we are anticipating the future need for maintaining a much larger system in which modifying every class in the clas hierarchy is going to be expensive and time-consuming. We need a better way and we begin by creating a new class PetVisitor, which will be applied to every Pet object(visit it) and perform the operations we need. First, we need to declare the class.

struct Cat;
struct Dog;

struct PetVisitor{
    virtual void visit(Cat* c) = 0;
    virtual void visit(Dog* d) = 0;
};

We had to forward declare the Pet hierarchy classes because PetVistor has to be declared before the concrete Pet classes. Now, we need to make the Pet hierarchy visitable, which means we do need to modify it, but only once, regardless of how many operations we want to add later. We need to add a virtual function to accept the Visitor pattern to every class that can be visited:

struct Pet{
    virtual void accept(PetVisitor& v) = 0;
    const std::string& color(){ return m_color; }

    Pet(std::string_view color) : m_color{ color }{}
    private:
    std::string m_color;
};

struct Cat : public Pet{
    Cat(std::string_view color) : Pet{ color }{}
    void accept(PetVisitor& v) override { v.visit(this); }
};

struct Dog : public Pet{
    Dog(std::string_view color) : Pet{ color }{}
    void accept(PetVisitor& v) override { v.visit(this); }
};

Now, our Pet hierarchy is visitable and we have an abstract PetVisitor class. Everything is ready to implement the new operations for our clases(note that nothing that we have done so far depends on what operations we are going to add; we have created the visiting infrastructure that has to be implemented once). The operations are added by implementing concrete Visitor classes derived from PetVisitor:

#include <print>
struct FeedingVisitor : public PetVisitor{
    void visit(Cat* c) override{
        std::println("Feed tuna to the {} cat", c->color());
    }

    void visit(Dog* d) override{
        std::println("Feed steak to the {} dog", dog->color());
    }
};

struct PlayingVisitor : public PetVisitor{
    void visit(Cat* c) override{
        std::println("Play with a feather with the {} cat", c->color());
    }

    void visit(Dog* d) override{
        std::println("Play fetch with the {} dog", d->color());
    }
};

Assuming the visitation infrastructure is already build into our class-hierarchy, we can implement a new operation by implementing a derived Visitor class, and all its virtual functions overrides for visit(). To invoke one of the new operations on an object from our class hierarchy, we need to create a visitor and visit the object:

Cat c{ "organge tabby" };
FeedingVisitor fv;
c.accept(fv);   // Feeding tuna to the organge tabby cat

This example of a call is too simple in one important way - at the point of calling the visitor, we know the exact type of the object we are visiting. To make the example more realistic, we have to visit an object polymorphically.

std::unique_ptr<Pet> p(new Cat("orange tabby"));
FeedingVisitor fv;
p->accept(fv);

Here, we do not know at compile-time the actual type of the object pointed to by p; at the point where the visitor is accepted, p could come from different sources. Whule less common, the visitor can also be used polymorphically:

std::unique_ptr<Pet> p(new Cat("orange tabby"));
std::unique_ptr<PetVisitor> v(new FeedingVisitor());
p->accept(*v);

Compiler Explorer

When written this way, the code highlights the double dispatch aspect of the visitor pattern - the call to accept() ends up dispatched to a particular visit() function based on two factors - the type of the visitable *p object and the type of the visitor *v object.

We now have the most bare-bones example of the class object-oriented visitor in C++. Despite its simplicity, it has all the necessary components: an implementation for a large real-life class hierarchgy and multiple visitor operations has a lot more code, but no new kinds of code, just more of things we have already done. This example shows both aspects of the Visitor pattern: on the one hand, if we focus on the functionality of the software, with the visitation infrastructure now in place, we can add new operations without any changes to the classes themselves. On the other hand, if we look just at the way the operation is invoked, the accept() call, we have implemented double dispatch.

We can immediately see the appeal of the Visitor pattern, we can add any number of new operations without having to modify every class in the hierarchy. If a new class is added to the Pet hierarchy, it is impossible to forget to handle it - if we do nothing at all to the visitor, the accept() call on the new class will not compile since there is no corresponding visit() function to call. Once we add the new visit() overload to the PetVisitor base class, we have to add it to all derived classes as well; otherwise the compiler will let us know that we have a pure virtual function without an override. The latter is also one of the main disadvantages of the Visitor pattern - if a new class is added to the hierarchy. all visitors must be updated, whether the new classes actually need to support these operations or not. For this reason, it is sometimes recommended to use the visitor only on relatively stable hierarchies that do not have new classes added often. There is also an alternative visitor implementation that somewhat mitigates this problem.

Visitor generalizations and limitations

Our very first visitor in the previous section allowed us to effectively add a virtual function to every class in the hierarchy. That virtual function had no parameters and no return value. The former is easy to extend, there is no reason at all why our visit() functions cannot have parameters. Let’s expand our class hierarchy by allowing our pets to be kittens and puppies. This extension cannot be done using only the Visitor pattern - we need to add not only new operations but also new data memebers. The Visitor pattern can be used for the former, but the latter requires code changes.

struct Pet{
    void add_child(Pet* p){ m_children.push_back(p); }
    virtual void accept(PetVisitor&v, Pet* p = nullptr) = 0;
    Pet(std::string_view color) : m_color{ color }{}
    const std::string& color(){ return m_color; }

    private:
    std::vector<Pet*> m_children;
    std::string       m_color;
};

Each parent Pet object tracks its child objects (note that the container is a vector of pointers, not a vector of unique pointers, so the object doesn’t own its children, but merely has access to them). We have also added the new add_child() member function to to add objects to the vector. We could have done this with a visitor, but this function is non-virtual, so we have to add it only once to the base class, not to every derived class - the visitor is unnecessary here. The accept() function has been modified to have an additional parameter that would have to be added to all derived classes as well, where it is simply forwarded to the visit() function:

struct Cat{
    
    Cat(std::string_view color) : Pet(color) {}

    void accept(PetVisitor& v, Pet* p = nullptr) override{
        v.visit(this, p);
    }
};

struct Dog : public Pet{
    public:
    Dog(std::string_view color) : Pet(color) {}
    void accept(PetVisitor& v, Pet* p = nullptr){
        v.visit(this, p);
    }
}

The visit() function also has to be modified to accept the additional argument, even for the visitors that do not need it. Changing the parameters of the accept() function is, therefore, an expensive global operation that should not be done often, if at all. Note that, all overrides for the same virtual function in the hierarchy already have to have the same parameters. The Visitor pattern extends this restriction to all operations added using the same base Visitor object. A common workaround for this is to pass parameters using aggregates (classes or structures that combine multiple parameters together). The visit() function is declared to accept a pointer to the base aggregate class, while each visitor receives a pointer to a derived class that may have additional fields, and uses them as needed.

Now, our additional argument is forwarded through the chain of virtual function calls to the visitor, where we can make use of it. Let’s create a visitor that records the pet births and adds new pet objects, as children to their parent objects:

#include <vector>
#include <print>
#include <memory>
#include <cassert>

struct Pet;
struct Cat;
struct Dog;

struct PetVisitor{
   virtual void visit(Cat* c, Pet* p = nullptr) = 0;
   virtual void visit(Dog* d, Pet* p = nullptr) = 0;
};

struct Pet{
   void add_child(Pet* p){ m_children.push_back(p); }
   virtual void accept(PetVisitor&v, Pet* p = nullptr) = 0;
   Pet(std::string_view color) : m_color{ color }{}
   const std::string& color(){ return m_color; }

   private:
   std::vector<Pet*> m_children;
   std::string       m_color;
};

struct Cat : public Pet{
   Cat(std::string_view color) : Pet{ color }{}
   void accept(PetVisitor& v, Pet* p = nullptr) override { v.visit(this, p); }
};

struct Dog : public Pet{
   Dog(std::string_view color) : Pet{ color }{}
   void accept(PetVisitor& v, Pet* p = nullptr) override { v.visit(this, p); }
};

struct FeedingVisitor : public PetVisitor{
   void visit(Cat* c, Pet* p = nullptr) override{
       std::println("Feed tuna to the {} cat", c->color());
   }

   void visit(Dog* d, Pet* p = nullptr) override{
       std::println("Feed steak to the {} dog", d->color());
   }
};

struct PlayingVisitor : public PetVisitor{
   void visit(Cat* c, Pet* p = nullptr) override{
       std::println("Play with a feather with the {} cat", c->color());
   }

   void visit(Dog* d, Pet* p = nullptr) override{
       std::println("Play fetch with the {} dog", d->color());
   }
};

struct BirthVisitor : public PetVisitor{
   void visit(Cat* c, Pet* child) override{
       assert(dynamic_cast<Cat*>(child));
       c->add_child(child);
       std::println("{} gave birth to child {}", c->color(), child->color());
   }

   void visit(Dog* d, Pet* child) override{
       assert(dynamic_cast<Dog*>(child));
       d->add_child(child);
       std::println("{} gave birth to child {}", d->color(), child->color());
   }
};

int main(){
   std::unique_ptr<Pet> parent(new Cat("orange tabby"));
   Pet* child(new Cat("calico"));

   std::unique_ptr<PetVisitor> pv(new PlayingVisitor());
   std::unique_ptr<PetVisitor> fv(new FeedingVisitor());
   BirthVisitor bv;

   parent->accept(*pv);   // Play with a feather with orange tabby cat
   parent->accept(*fv);   // Feeding tuna to the organge tabby cat
   parent->accept(bv, child);
}

Compiler Explorer

Once we have established the parenthood relationships, we want to examine our pet families. That is another operation we want to add, which calls for another visitor.

#include <print>

struct FamilyTreeVisitor : public PetVisitor{
   void visit(Cat* c, Pet* p) override{
       std::println("Kittens : ");
       for(auto k : c->m_children){
           std::println("{}", k->color());
       }
   }

   void visit(Dog* d, Pet* p) override{
       std::println("Puppies : ");
       for(auto p : d->m_children){
           std::println("{}", p->color());
       }
   }
};

We have hit a slight problem, though, because as written, the code will not compile. The reason is that the FamilyTreeVisitor is trying to access the Pet::m_children data member, which is private. THis is another weakness of the Visitor pattern - from our point of view, the visitors add new operations to the classes, just like virtual functions, but from the compiler’s point of view, they are completely separate classes, not at all like member functions of the Pet classes and have no special access. Application of the visitor pattern usually requires that the encapsulation is relaxed in one of two ways - we can either allow public access to the data(directly or through get member functions) or declare the Visitor classes to be friends. In our example, we will follow the second route:

#include <vector>
#include <print>
#include <memory>
#include <cassert>

struct Pet;
struct Cat;
struct Dog;

struct PetVisitor{
    virtual void visit(Cat* c, Pet* p = nullptr) = 0;
    virtual void visit(Dog* d, Pet* p = nullptr) = 0;
};

struct Pet{
    friend struct FamilyTreeVisitor;

    void add_child(Pet* p){ m_children.push_back(p); }
    virtual void accept(PetVisitor&v, Pet* p = nullptr) = 0;
    Pet(std::string_view color) : m_color{ color }{}
    const std::string& color(){ return m_color; }

    private:
    std::vector<Pet*> m_children;
    std::string       m_color;
};

struct Cat : public Pet{
    Cat(std::string_view color) : Pet{ color }{}
    void accept(PetVisitor& v, Pet* p = nullptr) override { v.visit(this, p); }
};

struct Dog : public Pet{
    Dog(std::string_view color) : Pet{ color }{}
    void accept(PetVisitor& v, Pet* p = nullptr) override { v.visit(this, p); }
};

struct FeedingVisitor : public PetVisitor{
    void visit(Cat* c, Pet* p = nullptr) override{
        std::println("Feed tuna to the {} cat", c->color());
    }

    void visit(Dog* d, Pet* p = nullptr) override{
        std::println("Feed steak to the {} dog", d->color());
    }
};

struct PlayingVisitor : public PetVisitor{
    void visit(Cat* c, Pet* p = nullptr) override{
        std::println("Play with a feather with the {} cat", c->color());
    }

    void visit(Dog* d, Pet* p = nullptr) override{
        std::println("Play fetch with the {} dog", d->color());
    }
};

 struct BirthVisitor : public PetVisitor{
    void visit(Cat* c, Pet* child) override{
        assert(dynamic_cast<Cat*>(child));
        c->add_child(child);
        std::println("{} gave birth to child {}", c->color(), child->color());
    }

    void visit(Dog* d, Pet* child) override{
        assert(dynamic_cast<Dog*>(child));
        d->add_child(child);
        std::println("{} gave birth to child {}", d->color(), child->color());
    }
 };


 struct FamilyTreeVisitor : public PetVisitor{
    void visit(Cat* c, Pet* p) override{
        std::println("Kittens");
        for(auto k : c->m_children){
            std::println("\t{}", k->color());
        }
    }

    void visit(Dog* d, Pet* p) override{
        std::println("Puppies");
        for(auto p : d->m_children){
            std::println("\t{}", p->color());
        }
    }
 };

int main(){
    std::unique_ptr<Pet> parent(new Cat("orange tabby"));
    Pet* child1(new Cat("calico"));
    Pet* child2(new Cat("garfield"));

    std::unique_ptr<PetVisitor> pv(new PlayingVisitor());
    std::unique_ptr<PetVisitor> fv(new FeedingVisitor());
    BirthVisitor bv;

    parent->accept(*pv);   // Play with a feather with orange tabby cat
    parent->accept(*fv);   // Feeding tuna to the organge tabby cat
    parent->accept(bv, child1);
    parent->accept(bv, child2);

    FamilyTreeVisitor tv;
    parent->accept(tv);
}

Compiler Explorer

Unlike BirthVisitor, FamilyTreeVisitor does not need the additional argument.

Now, we have visitors that implement operations with parameters. What about return values? Technically, there is no requirement for visit() and accept() functions to return void. They can return anything else. However, the limitation that they have to all return the same type usuallyt makes this capability useless. Virtual functions can have covariant return types, where the base class virtual function returns an object of some class and the derived class overrides return objects derived from that class, but even that is usually too limiting. There is another, much simpler solution - the visit() functions of every visitor object has full access to the data members of the object. THere is no reason why we cannot store the the return value in the Visitor class itself and access it later. This fits well with the most common use where each visitor adds a different operation and is likely to have a unique return type, but the operation itself usually has the same return type for all the classes in the hierarchy. For example, we can make our FamilyTreeVisitor count the total number of children and return the value through the visitor object.

#include <vector>
#include <print>
#include <memory>
#include <cassert>

struct Pet;
struct Cat;
struct Dog;

struct PetVisitor{
    virtual void visit(Cat* c, Pet* p = nullptr) = 0;
    virtual void visit(Dog* d, Pet* p = nullptr) = 0;
};

struct Pet{
    friend struct FamilyTreeVisitor;

    void add_child(Pet* p){ m_children.push_back(p); }
    virtual void accept(PetVisitor&v, Pet* p = nullptr) = 0;
    Pet(std::string_view color) : m_color{ color }{}
    const std::string& color(){ return m_color; }

    private:
    std::vector<Pet*> m_children;
    std::string       m_color;
};

struct Cat : public Pet{
    Cat(std::string_view color) : Pet{ color }{}
    void accept(PetVisitor& v, Pet* p = nullptr) override { v.visit(this, p); }
};

struct Dog : public Pet{
    Dog(std::string_view color) : Pet{ color }{}
    void accept(PetVisitor& v, Pet* p = nullptr) override { v.visit(this, p); }
};

struct FeedingVisitor : public PetVisitor{
    void visit(Cat* c, Pet* p = nullptr) override{
        std::println("Feed tuna to the {} cat", c->color());
    }

    void visit(Dog* d, Pet* p = nullptr) override{
        std::println("Feed steak to the {} dog", d->color());
    }
};

struct PlayingVisitor : public PetVisitor{
    void visit(Cat* c, Pet* p = nullptr) override{
        std::println("Play with a feather with the {} cat", c->color());
    }

    void visit(Dog* d, Pet* p = nullptr) override{
        std::println("Play fetch with the {} dog", d->color());
    }
};

 struct BirthVisitor : public PetVisitor{
    void visit(Cat* c, Pet* child) override{
        assert(dynamic_cast<Cat*>(child));
        c->add_child(child);
        std::println("{} gave birth to child {}", c->color(), child->color());
    }

    void visit(Dog* d, Pet* child) override{
        assert(dynamic_cast<Dog*>(child));
        d->add_child(child);
        std::println("{} gave birth to child {}", d->color(), child->color());
    }
 };


 struct FamilyTreeVisitor : public PetVisitor{
    FamilyTreeVisitor() : m_child_count{0uz} {}
    void reset(){ m_child_count = 0; }
    size_t get_child_count(){ return m_child_count; }

    void visit(Cat* c, Pet* p) override{
        visit_impl(c, "Kittens");
    }

    void visit(Dog* d, Pet* p) override{
        visit_impl(d, "Puppies");
    }

    private:
    size_t m_child_count;

    template<typename T>
    void visit_impl(T* t, const char* s){
        std::println("{}", s);
        for(auto p : t->m_children){
            std::println("\t{}", p->color());
            ++m_child_count;
        }
    }
 };

int main(){
    std::unique_ptr<Pet> parent(new Cat("orange tabby"));
    Pet* child1(new Cat("calico"));
    Pet* child2(new Cat("garfield"));

    std::unique_ptr<PetVisitor> pv(new PlayingVisitor());
    std::unique_ptr<PetVisitor> fv(new FeedingVisitor());
    BirthVisitor bv;

    parent->accept(*pv);   // Play with a feather with orange tabby cat
    parent->accept(*fv);   // Feeding tuna to the organge tabby cat
    parent->accept(bv, child1);
    parent->accept(bv, child2);

    FamilyTreeVisitor tv;
    parent->accept(tv);

    std::println("{} kittens total", tv.get_child_count());
}

Compiler Explorer

This approach imposes some limitations in multithreaded programs - the visitor is now not thread safe since multiple threads cannot use the same Visitor object to visit different pet objects. The most common solution is to use one visitor object per thread.

Let’s return for a moment and examine the FamilyTreeVisitor implementation again. Note that it iterates over the child objects of the parent object and calls the same operation on each one, in turn. It does not, however, process the children of the child object - our family tree is only one-generation deep. The problem of visiting objects that contain other objects is very general and occurs rather often. Our motivational example - the problem of serialization demonstrates this need perfectly - every complex object is serialized by serializing its components one by one and they in turn are serialized the same way, until we get all the way down to the built-in types such as int and double which we know to read and write.

Visiting complex objects

In the last section, we saw, how the Visitor pattern allows us to add new operations to the existing hierarchy. In one of the examples, we visited a complex object that contained pointers to other objects. The visitor iterated over these pointers, in a limited way. We are now going to consider the general problem of visiting objects that are composed of other objects, or objects that contain other objects and build up to the demonstration of a working serialization./deserialization solution at the end.

struct Shelter{
    void add(Pet* p){
        m_pets.emplace_back(p);
    }

    void accept(PetVisitor& v){
        for(auto& p : m_pets){
            p->accept(v);
        }
    }

    private:
    std::vector<std::unique_ptr<Pet>> m_pets;
};

struct Family{
    public:
    Family(const car* cat_color, const char* dog_color)
    : m_cat{ cat_color }
    , m_dog{ dog_color }
    {}

    void accept(PetVisitor& v){
        m_cat.accept(v);
        m_dog.accept(v);
    }

    private:
    Cat m_cat;
    Dog m_dog;
};

Serialization and Deserialization with visitor

The problem itself was described in detail in the previous section - for serialization, each object needs to be converted to a sequence of bits, and these bits need to be stored, copied or sent. The first part of the action depends on the object(each object is converted differently), but the second part depends on the specific application of the serialization(saving to the disk is different from sending across the network). The implementation depends on two factors, hence the need for double dispatch, which is exactly what the Visitor pattern provides. Furthermore, if we have a way to serialize some object and then deserialize it (reconstruct the object from the sequence of bits), we should use the same method when this object is included in another object.

To demonstrate serialization/deserialization of a class hierarchy using the Visitor pattern. we meed a more complex hierarchy than the toy examples we have used so far. Let’s consider this hierarchy of two-dimensional geometric objects:

struct Geometry{
    virtual ~Geometry(){}
};

struct Point : public Geometry{
    Point() = default;
    Point(double x, double y) : x_{x}, y_{y}
    {}

    private:
    double x_;
    double y_;
};

struct Circle : public Geometry{
    Circle() = default;
    Circle(Point center, double radius) 
    : center_{ center }
    , radius_{ radius }
    {}

    private:
    Point center_;
    double radius_;
};

struct Line : public Geometry{
    Line() = default;
    Line(Point p1, Point p2) 
    : p1_{ p1 }
    , p2_{ p2 }
    {}

    private:
    Point p1_;
    Point p2_;
}

All objects derived from the abstract Geometry base class, but the more complex object contains one or more of the simpler objects; for example, Line is defined by two Point objects. Note that, at the end of the day, all our objects are made of double numbers, and therefore, will serialize into a sequence of numbers. The key is knowing, which double represents which field of which object: we ned this to restore the original objects correctly.

To serialize these objects using the Visitor pattern, we follow the same process we used in the last section. First, we need to declare the base Visitor class:

struct Visitor{
    virtual void visit(double& x) = 0;
    virtual void visit(Point& p) = 0;
    virtual void visit(Circle& c) = 0;
    virtual void visit(Line& l) = 0;
};

There is one additional detail here - we can also visit double values; each visitor would need to handle them appropriately(write them, read them and so on). Visiting any geometry object will result, eventually, in visiting the numbers it is composed of.

Our base Geometry class and all classes derived from it need to accept this visitor:

struct Geometry{
    virtual ~Geometry(){}
    virtual void accept(Visitor& v) = 0;
};

There is of course, no way to add an accept() member function to double, but we won’t have to. The accept() member functions of the derived classes, each of which is composed of one or more members and other classes, visit every data member in order:

void Point::accpet(Visitor& v){
    v.visit(x_);
    v.visit(y_);
}

void Circle::accept(Visitor& v){
    v.visit(center_);
    v.visit(radius_);
}

void Line::accept(Visitor& v){
    v.visit(p1_);
    v.visit(p2_);
}

The concrete Visitor classes, all derived from the base Visitor class, are responsible for the specific mechanisms of serialization and deserialization. The order in which the objects are broken down into their parts, all the way down to the numbers, is controlled by each object, but the visitors determine what is done with these numbers. For example, we can serialize all objects into a string using formatted I/O(similar to what we get if we print the numbers into cout).

struct StringSerializeVisitor : public Visitor{
    void visit(double& x) override{
        sstream_ << x << " ";
    }
    void visit(Point& p) override{
        p.accept(*this);
    }

    void visit(Line& l) override{
        l.accept(*this);
    }

    std::string str(){
        return sstream_.str();
    }

    private:
    std::stringstream sstream_;
};

The string is accumulated in stringstream until all the ncessary objects are serialized.

Point p1{1.0, -1.0};
Point p2{3.0, 4.0};
Line l{p1, p2};
Circle c{p1, 5.0};

StringSerializeVisitor serializer;
serializer.visit(l);
serializer.visit(c);
std::string s{serializer.str()};

Now, that we have the objects printed into the s string, we can also restore them from this string perhaps on a different machine(if we arranged for the string to be sent there). First, we need the deserializing visitor:

struct StringDeserializeVisitor : public Visitor{
    StringDeserializeVisitor(const std::string& s){
        sstream_.str(s);
    }

    
};

std::variant usage

The std::variant template is essentially a smart union. std::variant<T1, T2, T3> is similar to union{T1 v1; T2 v2; T3 v3} in that both can store a value of one of the specified types and only one value can be stored at a time. The key difference is that a variant objects knows which type it contains, while with a union the programmer is wholly responsible for reading the same type as what was written earlier. It is undefined behavior to access a union as a type that differs from the one used to initialize it:

In contrast std::variant offers a safe way to store values of different types in the same memory. It is easy to check at runtime which alternative type is currently stored in the vartiant, and accessing a variant as the wrong type throws an exception.

std::variant<int, double, std::string> v;
v = 0;
std::cout << v.index();
++std::get<0>(v);
// std::get<1>(v);  //throws std::bad_variant_access

In many ways, std::variant offers capabilities similar to inheritance-based run-timne polymorphism: both let us write code where the same variable name can refer to objects of different types at run-time. The two major differences are: first, a std::variant does not require that all its types come from the same hierarchy(they need not be classes at all) and second, a variant object can only store one of the types listed in its declaration, while a base class pointer can point to any derived class.

Visitors are objects that are used to implement the Visitor design pattern. Typically, they are used to add an operation to all classes in a class hierarchy, that is the equivalent of adding a virtual function, but without modifying the classes themselves. When a visitor object visits a variant, they invoke the best matching function call operator for the actual value of the variant.

#include <variant>
#include <string>
#include <iostream>

struct MyVisitor{
    void operator()(int i) const{
        std::cout << "int: " << i << "\n";
    }

    void operator()(std::string s) const{
        std::cout << "string: " << s << "\n"; 
    }

    void operator()(double d) const{
        std::cout << "double: " << d << "\n";
    }
};

int main(){
    std::variant<int, std::string, double> var(42);
    std::visit(MyVisitor(), var);   // calls operator()(int)

    var = "hello";
    std::visit(MyVisitor(), var);   // calls operator()(std::string)

    var = 3.14;
    std::visit(MyVisitor(), var);   // calls operator()(double)
    return 0;
}

Compiler Explorer

Using generic lambdas as visitors

#include <variant>
#include <string>
#include <iostream>

auto printVisitor() = [](const auto& v){
    std::cout << "\n" << v;
};

int main(){
    std::variant<int, std::string, double> var(42);
    std::visit(printVisitor, var);
    var = "hello";
    std::visit(printVisitor, var);
    var = 42.7;
    std::visit(printVisitor, var);
    return 0;
}

The cracked-man’s match

template<typename... Ts>
struct overload : Ts... {
    using Ts::operator()...;
};

// base types are deduced from the passed arguments
template<typename... Ts>
overload(Ts...) -> overload<Ts...>;

int main(){
    std::variant<int, std::string> var(42);
    std::visit(overload{
        [](int i){ std::cout << "\n" << "int : " << i; },
        [](std::string s){ std::cout << "\n" << "string : " << s; }
        [](double d){ std::cout << "\n" << "double : " << d; }
    }, var);
}

Since the struct overload inherits from the closure types (__my_lambda_with_int_param_struct and __my_lambda_with_string_param_struct), we need to bring their function call operators in scope.

#include <string>
#include <variant>
#include <stdexcept>

template<typename... Ts>
struct overloaded : public Ts...{
    using Ts::operator()...;
};

// base types are deduced from passed arguments
template<typename... Ts>
overloaded(Ts...) -> overloaded<Ts...>;

struct Cell{
    std::variant<int, std::string> data;

    Cell& operator+=(Cell& other){
        std::visit(overloaded{
            [](int a, int b){ a += b; },
            [](std::string a, int b){ a += std::to_string(b); },
            [](int a, std::string b){ throw std::runtime_error("Invalid inputs!"); },
            [](std::string a, std::string b){ a += b; }
        }, data, other.data);

        return *this;
    }
};

int main(){}

What is a std::variant under the hood?

// Pseudo-code
namespace dev{
    template<typename... Ts>
    struct variant{
        union{
            Ts... elements;
        };

        // ....
        index_type index;
    };

    auto visit(auto&& visitor, auto&&... args){
        switch(...)
            case 0:
                visitor.visit(get<0>(args)...);
            case 1:
                visitor.visit(get<1>(args)...);
    }
}

Under the hood, a std::variant is a union of all of the possible alternatives. It has an active index. And then, in visit there is some sort of switch statement, between all of the possible types. And we’re going to implement all of these components.

TMP Utilities

We are going to start with just a bunch of template metaprogramming utilities.

#include <print>
#include <concepts>
#include <initializer_list>
#include <string>

namespace dev{

namespace tools{
    namespace type_lists{
        template<typename T, typename... Ts>
        constexpr size_t find_index_of_impl(){
            size_t i{0uz};
            for(bool is_same_type : { std::is_same_v<T, Ts>... }){
                if(is_same_type)
                    break;

                ++i;
            }

            return i;
        }

        // define a concept that checks if the index is not
        // out of bounds
        template<typename T, typename... Ts>
        concept out_of_bounds_check = (
            find_index_of_impl<T,Ts...>() < sizeof...(Ts)
        );
    } // namespace type_lists

    template<typename T, typename... Ts>
    requires type_lists::out_of_bounds_check<T, Ts...>
    constexpr size_t find_index_of_v = type_lists::find_index_of_impl<T,Ts...>();

    template<typename T, typename... Ts>
    concept exists = requires{
        { find_index_of_v<T,Ts...> };
    };

} // namespace tools

}

// -------------- tests ------------
static_assert(dev::tools::find_index_of_v<int, int, float, double> == 0);
static_assert(dev::tools::find_index_of_v<float, int, float, double> == 1);
static_assert(dev::tools::exists<double, int, float, std::string, double>);
static_assert(!dev::tools::exists<std::string, int, float>);

int main(){}

#include <cstdint>
// -------------- tests ------------
static_assert(std::same_as<uint8_t,dev::tools::uint_atleast<100>>);
static_assert(std::same_as<uint8_t,dev::tools::uint_atleast<255>>);
static_assert(std::same_as<uint16_t,dev::tools::uint_atleast<256>>);
static_assert(std::same_as<uint32_t,dev::tools::uint_atleast<std::numeric_limits<uint32_t>>>);
static_assert(std::same_as<uint64_t,dev::tools::uint_atleast<5'000'000'000>>);

namespace dev{

namespace tools{
    template<size_t max>
    using uint_atleast_t = decltype(int_utils::uint_atleast_impl<max>());
}

}

#include <cstdint>

namespace dev{

namespace tools{
    namespace int_utils{
        template<size_t max>
        constexpr auto uint_atleast_impl(){
            if constexpr(max <= std::numeric_limits<std::uint8_t>::max())
                return uint8_t{};
            else if constexpr(max <= std::numeric_limits<std::uint16_t>::max())
                return uint16_t{};
            else if constexpr(max <= std::numeric_limits<std::uint32_t>::max())
                return uint32_t{};
            else if constexpr(max <= std::numeric_limits<std::uint64_t>::max())
                return uint64_t{};                
        }
    }
    
    template<size_t max>
    using uint_atleast_t = decltype(int_utils::uint_atleast_impl<max>());
    
}

// -------------- tests ------------
static_assert(std::is_same_v<uint8_t, dev::tools::uint_atleast_t<100>>);
static_assert(std::is_same_v<uint8_t, dev::tools::uint_atleast_t<255>>);
static_assert(std::is_same_v<uint16_t, dev::tools::uint_atleast_t<256>>);
static_assert(std::is_same_v<uint32_t, dev::tools::uint_atleast_t<std::numeric_limits<uint32_t>>>);
static_assert(std::is_same_v<uint64_t, dev::tools::uint_atleast_t<5'000'000'000>>);

namespace dev{
namespace tools{
    namespace type_lists{
        template <size_t n,
                  typename T0 = void,
                  typename T1 = void,
                  typename T2 = void,
                  typename T3 = void,
                  typename T4 = void,
                  typename T5 = void,
                  typename T6 = void,
                  typename T7 = void,
                  typename T8 = void,
                  typename T9 = void,
                  typename... Ts>
        constexpr auto get_nth_type_impl(){
            /**/ if constexpr ( n == 0 ) return std::type_identity<T0>{};
            else if constexpr ( n == 1 ) return std::type_identity<T1>{};
            else if constexpr ( n == 2 ) return std::type_identity<T2>{};
            else if constexpr ( n == 3 ) return std::type_identity<T3>{};
            else if constexpr ( n == 4 ) return std::type_identity<T4>{};
            else if constexpr ( n == 5 ) return std::type_identity<T5>{};
            else if constexpr ( n == 6 ) return std::type_identity<T6>{};
            else if constexpr ( n == 7 ) return std::type_identity<T7>{};
            else if constexpr ( n == 8 ) return std::type_identity<T8>{};
            else if constexpr ( n == 9 ) return std::type_identity<T9>{};
            else                         return get_nth_type_impl<n-10, Ts...>();
        }
    } // namespace type_lists

    template<size_t n, typename... Ts>
    requires(n < sizeof...(Ts))
    using get_nth_type_t = typename decltype(type_lists::get_nth_type_impl<n, Ts...>())::type;
} // namespace tools
}

// -------------- tests ------------
static_assert(std::is_same_v<
    dev::tools::get_nth_type_t<0, char, short, int, long, float, double>, 
    char>);

static_assert(std::is_same_v<
    dev::tools::get_nth_type_t<5, char, short, int, long, float, double>, 
    double>);

// -------------- tests ------------
static_assert(dev::tools::instance_of<std::vector<int>, std::vector>);
static_assert(!dev::tools::instance_of<int, std::vector>);
static_assert(!dev::tools::instance_of<std::vector<int>&, std::vector>);

template<template <typename ...> class Template, typename What>
//       ^--------------------------------^       ^--------^
//       1st param: a template that accepts       2nd param: a
//       any number of args                       concrete type
struct impl : std::false_type {};

template<template<typename...> typename What, typename... Ts>
        struct impl<What, What<Ts...>> : std::true_type {};

#include <vector>

namespace dev{
namespace tools{
    namespace _instance_of{
        template<template <typename...> typename Template, typename What>
        //       ^--------------------------------^       ^--------^
        //       1st param: a template that accepts       2nd param: a
        //       any number of args                       concrete type        
        struct impl : std::false_type {};

        template<template<typename...> typename What, typename... Ts>
        struct impl<What, What<Ts...>> : std::true_type {};
    }

    template<typename T, template <typename... > typename Template>
    concept instance_of = _instance_of::impl<Template, T>::value;
} // namespace tools 
}

// -------------- tests ------------
static_assert(dev::tools::instance_of<std::vector<int>, std::vector>);
static_assert(!dev::tools::instance_of<int, std::vector>);
static_assert(!dev::tools::instance_of<std::vector<int>&, std::vector>);

std::forward<decltype(x)>(x);

#define TOOLS_FWD(...)
    static_cast<decltype(__VA_ARGS__)&&>(__VA_ARGS__)

union_ type definition

The union_ type is something which is used to store the data. It is similar to the built-in union but it allows unpacking. That is, you could, for example request to construct the element at index 2 or get the element at index 2.

Let’s first understand how to write the union_ type. A while back people just created a bunch of chars - a buffer area to accomodate the largest type and they would cast pointers to the alternative types in the union.

The modern approach is to write a recursive solution. Using some mathematical formalism, the union of N+1 types T0, T1, ..., TN written is equivalent to pulling out the first type, union’ing with the union of the rest of the types, that is . In code:

template<typename First, typename... Rest>
struct union_{
    union{
        First head;
        union_<Rest...> tail; 
    }
};

A union must contain atleast one type. This is the default case.

template<typename T>
struct union_<T>{
    T head;
};

We implement some constructors. There is a default constructor, a constructor for the head and a constructor for the Ith element.

The API of these constructors is templated by a parameter size_t I - the index of the element to be constructed. The first argument to the constructor is of the type std::in_place_index_t, which is simply a wrapper type for storing indexes at compile-time.

namespace dev{
namespace tools{

    template<typename First, typename... Rest>
    struct union_{
        union{
            First head;
            union_<Rest...> tail; 
        }

        constexpr union_() = default;
        constexpr union_(std::in_place_index_t<0u>, auto&&... args)
        : head{ TOOLS_FWD(args)... }
        {}

        template<size_t I>
        constexpr union_(std::in_place_index_t<I> idx, auto&&... args)
        : tail{ std::in_place_index<I - 1>{}, TOOLS_FWD(args)... }
        {}
    };

    template<typename T>
    struct union_<T>{
        T head;

        constexpr union_() = default;
        constexpr union_(std::in_place_index_t<0u>, auto&&... args)
        : head{ TOOLS_FWD(args)... }
        {}
    };

} // namespace tools
}

namespace dev{
namespace tools{
    template<typename>
    struct union_size;

    template<typename... Ts>
    struct union_size<union_<Ts...>>
    : std::integral_constant<size_t, sizeof...(Ts)>
    {}

    template <typename Union>
    constexpr size_t union_size_v = union_size<Union>::value;
} // namespace tools
}

namespace dev{
namespace tools{
    template<size_t i, typename Self>
    constexpr auto&& get(Self&& self)
    requires instance_of<std::remove_cvref_t<Self>, union_> &&
    (i < union_size<std::remove_cvref_t<Self>>)
    {
        if constexpr(i == 0)
            return TOOLS_FWD(self).head;
        else
            return get<i - 1>(TOOLS_FWD(self).tail);
    }
} // namespace tools
}

namespace dev{
namespace tools{
    template<size_t i, typename... Ts>
    constexpr void construct_at(union_<Ts...>& self, auto&&... args){
        // std::construct_at(<address>, <ctor args>...)
        std::construct_at(&get<i>(self), std::in_place_index<i>, TOOLS_FWD(args)...);
    }

    template<size_t i, typename... Ts>
    constexpr void destroy_at(union_<Ts...>& self){
        // std::destroy_at(<address>)
        std::destroy_at(&get<i>(self));
    }
} // namespace tools
}

Wrapping it up - the variant class

A basic implementation is listed below. Perhaps, the most challenging problem to solve is writing a destructor/copy ctor.

When implementing ~variant() we know the active index, so we can use std::get<I> to get underlying T object. However, template<size_t I> std::get() and other meta-functions are designed to accept compile-time constants as template parameters. We don’t know, the active index until run-time.

The solution is to generate an array of if-conditionals, at compile-time using pack expansion of the form:

// Generate if-conditionals sizeof...(Ts) times
if(m_idx == 0)
    tools::destroy_at<0>(m_data);
else if(m_idx === 1)
    tools::destroy_at<1>(m_data);
//...

We use std::index_sequence for this purpose, which represents a compile-time sequence of numbers. We construct the sequence 0,1,2,3,...,sizeof...(Ts)-1 and then define a lambda function that accepts this as a parameter pack Indices. Inside the lambda function, we use a ternary expression to check if the active index m_idx == Indices (the pack variable) and perform destruction in the true case. We apply C++17 fold expressions to expand Indices and generate multiple if statements.

// Destructor
constexpr ~variant(){
   constexpr auto idx_seq = std::make_index_sequence<sizeof...(Ts)>();
   [&]<auto... Indices>(std::index_sequence<Indices...>){
       (((m_idx == Indices) ? (tools::destroy_at<Indices>(m_data), 0) : 0), ...);
   }(idx_seq);
}

namespace dev{

    template<typename... Ts>
    class variant;

    // Forward declaration 
    // so the friend declaration inside variant resolves
    template<size_t I, typename... Ts>
    constexpr decltype(auto) get(const variant<Ts...>& v);

    template<typename T, typename... Ts>
    constexpr T& get(const variant<Ts...>& v);

    template<typename... Ts>
    class variant{
        using index_type = tools::uint_atleast_t<sizeof...(Ts)>;
        static constexpr size_t size = sizeof...(Ts);

        tools::union_<Ts...> m_data;
        index_type m_idx;

        public:
        /**
         * @brief: Constructs a variant holding the zero-initialized value 
         * of the first alternative.
         */
        constexpr variant()
        {
            tools::construct_at<0>(m_data, tools::get_nth_type_t<0, Ts...>());
            m_idx = 0;
        }

        /**
         * @brief Converting constructor. Constructs a variant holding the
         * alternative of type @p T, from @p x.
         */
        template<tools::exists<Ts...> T>
        constexpr explicit variant(T&& x){
            tools::construct_at<tools::find_index_of_v<T, Ts...>>(m_data, TOOLS_FWD(x));
            m_idx = tools::find_index_of_v<T, Ts...>;
        }

        /**
         * @brief Copy constructor. Constructs a variant holding the same
         * alternative as @p other, copy-constructed from the contained value.        
         */
        constexpr variant(const variant& other){
            index_type idx = other.m_idx;
            constexpr auto idx_seq = std::make_index_sequence<sizeof...(Ts)>();
            [&]<auto... Indices>(std::index_sequence<Indices...>){
                (((idx == Indices) 
                ? (tools::construct_at<Indices>(m_data, tools::get<Indices>(other.m_data)), 0) 
                : 0), ...);
            }(idx_seq);
            m_idx = idx;
        }

        /**
         * @brief Move constructor. Steals data from @p other. 
         * Constructs a variant holding the same
         * alternative as @p other, move-constructed from 
         * the contained value.
         */
        constexpr variant(variant&& other) noexcept{
            index_type idx = other.m_idx;
            constexpr auto idx_seq = std::make_index_sequence<sizeof...(Ts)>();
            [&]<auto... Indices>(std::index_sequence<Indices...>){
                (((idx == Indices) 
                ? (tools::construct_at<Indices>(m_data, tools::get<Indices>(std::move(other.m_data))), 0) 
                : 0), ...);
            }(idx_seq);
            m_idx = idx;
        }

        /**
         * @brief Swaps the contents of two variants.
         *
         * If both variants hold the same alternative (index() == other.index()),
         * the contained values are swapped directly via @c std::swap. Otherwise,
         * the alternatives are exchanged by using a temporary.
         */
        void swap(variant<Ts...>& other) noexcept{
            using std::swap;
            if(m_idx == other.m_idx){
                //swap(get<m_idx>(*this), tools::get<m_idx>(other));
                return [&]<size_t... Idxs>(std::index_sequence<Idxs...>){
                    (((m_idx == Idxs) ? (swap(get<Idxs>(*this), get<Idxs>(other)), 0) : 0), ...);
                }(std::make_index_sequence<sizeof...(Ts)>());
            }else{
                auto p = std::move(*this);
                std::construct_at(this, std::move(other));
                std::construct_at(&other, std::move(p));
            }
        }

        /**
         * @brief Copy assignment operator.
         */        
        variant<Ts...>& operator=(const variant<Ts...>& other){
            variant(other).swap(*this);
            return *this;
        }

        /**
         * @brief Move assignment operator.
         */        
        variant<Ts...>& operator=(variant<Ts...>&& other) noexcept{
            variant(std::move(other)).swap(*this);
            return *this;
        }

        /**
         * @brief Converting assignment operator. Assigns a value of type
         * @p T to the variant.
         */
        template<tools::exists<Ts...> T>
        constexpr variant<Ts...>& operator=(T&& element){
            this->~variant();
            constexpr size_t i = tools::find_index_of_v<T, Ts...>;
            tools::construct_at<i>(m_data, TOOLS_FWD(element));
            m_idx = i;
            return *this;
        }

        /**
        * @brief Destructor. Destroys the currently held alternative.
        */
        constexpr ~variant(){
            constexpr auto idx_seq = std::make_index_sequence<sizeof...(Ts)>();
            [&]<auto... Indices>(std::index_sequence<Indices...>){
                (((m_idx == Indices) ? (tools::destroy_at<Indices>(m_data), 0) : 0), ...);
            }(idx_seq);
        }

        /**
         * @brief Returns the zero-based index of the alternative currently
         * held by the variant.
         */
        constexpr std::size_t index() const noexcept{
            return m_idx;
        }

        template<size_t I, typename... Us>
        constexpr friend decltype(auto) get(const variant<Us...>& v);

        template<typename T, typename... Us>
        constexpr friend T& get(const variant<Us...>& v);

        template<size_t I, typename... Us>
        constexpr friend decltype(auto) get(variant<Us...>& v);

        template<typename T, typename... Us>
        constexpr friend T& get(variant<Us...>& v);
    }; 

    template<size_t I, typename... Ts>
    constexpr decltype(auto) get(const variant<Ts...>& v){
        return tools::get<I>(v.m_data);
    }

    template<typename T, typename... Ts>
    constexpr T& get(const variant<Ts...>& v){
        return tools::get<tools::find_index_of_v<T, Ts...>>(v.m_data);
    }

    template<size_t I, typename... Ts>
    constexpr decltype(auto) get(variant<Ts...>& v){
        return tools::get<I>(v.m_data);
    }

    template<typename T, typename... Ts>
    constexpr T& get(variant<Ts...>& v){
        return tools::get<tools::find_index_of_v<T, Ts...>>(v.m_data);
    }
}