Data Alignment in C++ — What It Is, Why It Hurts When Ignored, and How to Fix It with new C++11/C++17 features

I’ve seen a lot of C++ code where people spend days chasing subtle bugs or unexplained performance regressions and the culprit ends up being something they never considered: memory alignment. It’s one of those topics that sits in the background quietly until it absolutely isn’t quiet anymore. So let’s go through it properly.

The Physical Reality First

Your CPU doesn’t read memory one byte at a time. It reads it in chunks — 4 bytes, 8 bytes, 16 bytes depending on the architecture and the operation. These chunks are aligned to specific boundaries in memory. A 4-byte integer is “naturally aligned” when it lives at an address divisible by 4. An 8-byte double is naturally aligned at an address divisible by 8.

When you write:

int x = 42;

The compiler quietly makes sure x ends up at an address like 0x7ffc1234 (divisible by 4), not 0x7ffc1235. You never had to ask. It just happened.

That automatic behavior is alignment. But understanding why it matters changes how you think about data layout entirely.

Here’s how the CPU sees memory. It can only fetch at aligned boundaries, in fixed-width chunks:

Address:       0x00  0x01  0x02  0x03  0x04  0x05  0x06  0x07
               +-----+-----+-----+-----+-----+-----+-----+-----+
               |     |     |     |     |     |     |     |     |
               +-----+-----+-----+-----+-----+-----+-----+-----+

int at 0x00:  [==========int (4B)==========]
              ^--- aligned (0x00 % 4 == 0), single read   ✓

int at 0x04:                            [=====int (4B)=====]
                                        ^--- aligned (0x04 % 4 == 0), single read   ✓

int at 0x01:         [==========int (4B)==========]
                     ^--- unaligned (0x01 % 4 != 0), straddles boundary   ✗
                      x86: two reads, slower
                      ARM: SIGBUS crash

int at 0x02:                 [==========int (4B)==========]
                              ^--- unaligned (0x02 % 4 != 0), straddles boundary   ✗
                              x86: two reads, slower
                              ARM: SIGBUS crash

What “Alignment Requirement” Actually Means ?

Every fundamental type in C++ has two properties most people know — its size — and one property most people ignore — its alignment requirement.

The alignment requirement of a type is the number of bytes its starting address must be divisible by, for the CPU to be able to read or write it correctly in a single operation.

Here’s roughly what that looks like on most 64-bit platforms:

| Type        | Size    | Alignment |
|-------------|---------|-----------|
| `char`      | 1 byte  | 1         |
| `short`     | 2 bytes | 2         |
| `int`       | 4 bytes | 4         |
| `float`     | 4 bytes | 4         |
| `double`    | 8 bytes | 8         |
| `long long` | 8 bytes | 8         |
| pointer     | 8 bytes | 8         |

The rule is simple: a type’s alignment is almost always equal to its size, up to some platform-defined maximum. So a double sitting at address 0x1000 is fine. A double at 0x1001 is a problem.

On x86 and x64, misaligned access doesn’t usually crash your program — the CPU handles it in hardware, but it takes more clock cycles. On ARM and some other architectures, misaligned access will crash your program outright with a bus error. This difference is a trap for people who develop on x86 and then deploy elsewhere.

Padding: The Compiler Adding Invisible Bytes

The compiler has to satisfy the alignment requirements of every field in a struct. Since it can’t move fields around (that would break serialization, ABI compatibility, all sorts of things), it inserts padding — invisible, unused bytes — between fields and at the end of the struct to keep everything aligned.

Here’s the classic example:

struct Bad {
    char a;     // 1 byte
    int b;      // 4 bytes — needs to be at offset divisible by 4
    char c;     // 1 byte
};

You might expect this to be 6 bytes. It’s actually 12. Here’s what’s really sitting in memory:

struct Bad — 12 bytes total

  Offset:  0     1     2     3     4     5     6     7     8     9    10    11
           +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
           |  a  |/////|/////|/////|           b (int)           |  c  |/////|/////|/////|
           +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
            char  <---3 bytes padding--->  <------4 bytes------->  char <---3 bytes pad--->

           Why the first gap?  'b' (int) needs offset divisible by 4. offset 1 is not, so pad to 4.
           Why the tail gap?   sizeof(Bad) must be a multiple of 4 (its largest alignment).
                               After 'c' at offset 8, next multiple of 4 is 12. So 3 bytes appended.

Now reorder the fields — largest alignment first:

struct Good {
    int b;      // 4 bytes
    char a;     // 1 byte
    char c;     // 1 byte
    // 2 bytes padding at end
};

struct Good — 8 bytes total

  Offset:  0     1     2     3     4     5     6     7
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |           b (int)           |  a  |  c  |/////|/////|
           +-----+-----+-----+-----+-----+-----+-----+-----+
            <---------4 bytes-----------> char  char  <-2B pad->

           Same data. No internal gaps. Only 2 bytes of unavoidable tail padding.
           33% smaller than Bad.

The 3 bytes after a in Bad exist because b needs to start at an offset divisible by 4. The 3 bytes at the end exist because the struct's overall size must be a multiple of its largest member alignment (4), so that arrays of this struct work correctly element-to-element.

You can verify this yourself:

#include <iostream>

struct Bad  { char a; int b; char c; };
struct Good { int b; char a; char c; };

int main() {
    std::cout << sizeof(Bad)  << "\n";  // 12
    std::cout << sizeof(Good) << "\n";  // 8
}

This matters a lot in practice. If you have a struct you’re storing a million copies of, that’s 4MB of wasted memory per million instances just from bad field ordering.

The Golden Rule for Field Ordering:

Sort fields by alignment requirement, largest first:

  BAD order:                        GOOD order:
  +---------+                       +---------+
  | char(1) |  ← 1B                 | dbl (8) |  ← 8B, no gap needed
  +---------+                       +---------+
  |///pad///|  ← 7B wasted          | int (4) |  ← 4B, still aligned
  +---------+                       +---------+
  | dbl (8) |  ← 8B                 | int (4) |  ← 4B
  +---------+                       +---------+
  | int (4) |  ← 4B                 | char(1) |  ← 1B
  +---------+                       +---------+
  | int (4) |  ← 4B                 | char(1) |  ← 1B
  +---------+                       +---------+
  | char(1) |  ← 1B                 |//2B pad/|  ← only 2B tail pad
  +---------+                       +---------+
  |///7B pad|  ← 7B wasted
  +---------+
  Total: 32B (14B wasted)           Total: 22B (2B wasted)

Why Misalignment Causes Real Problems

Performance on x86/x64: The CPU reads memory in aligned chunks. When data is misaligned, it might straddle two cache lines. Reading a misaligned 8-byte value that sits across a cache line boundary means two cache line reads instead of one. On tight loops this adds up fast.

Cache line 0 (bytes 0–63)              Cache line 1 (bytes 64–127)
  +--------------------------------------+--------------------------------------+
  | .. .. .. .. .. .. .. .. .. .. [XX XX | XX XX XX XX XX XX] .. .. .. .. .. . |
  +--------------------------------------+--------------------------------------+
                                   ^-----------double (8B)------------^
                                          split across two lines!
                                          two fetches to read one value

  vs. aligned:
  +--------------------------------------+
  | .. [XX XX XX XX XX XX XX XX] .. .. . |
  +--------------------------------------+
        ^---------double (8B)---------^
        fits in one line, one fetch

Crashes on Other Architectures: Many ARM processors require strict alignment. If you cast a char* buffer to an int* and the buffer doesn't happen to be 4-byte aligned, you'll get a SIGBUS. This happens all the time in network code where people deserialize raw byte streams:

// This is dangerous
void parse(const char* buf) {
    int value = *reinterpret_cast<const int*>(buf + 1); // buf+1 is not 4-byte aligned
}

buf:    0x1000  0x1001  0x1002  0x1003  0x1004
          +-------+-------+-------+-------+-------+
          |  hdr  |  [d0] |  [d1] |  [d2] |  [d3] |
          +-------+-------+-------+-------+-------+
                   ^--- casting buf+1 to int*
                        address 0x1001, not divisible by 4

  x86: silently does two reads, merges, returns result (slower)
  ARM: raises SIGBUS — program crashes

On x86 this works (slowly). On ARM this crashes.

SIMD and Vectorization SSE and AVX instructions require or strongly prefer 16 or 32-byte aligned data. Unaligned SIMD loads exist but are slower. If you’re writing anything performance-sensitive and expecting the compiler to auto-vectorize, misaligned data will either prevent vectorization entirely or generate slower code paths.

SSE register = 128 bits = 16 bytes

  Aligned (addr % 16 == 0):
  addr 0x10  [f0][f1][f2][f3]
              ^--- MOVAPS: single fast aligned load - GOOD

  Unaligned (addr % 16 != 0):
  addr 0x11   [f0][f1][f2][f3]
               ^--- must use MOVUPS (slower) or
                    two MOVAPS + shuffle - BAD

Atomics On some platforms, atomic operations on misaligned addresses are not atomic at all. The standard says atomic operations on std::atomic<T> are only guaranteed to be lock-free if the object is properly aligned. If it's not, you may be silently falling back to a mutex, or on some platforms, getting torn reads.

Properly aligned std::atomic<int> at 0x1000:
  +-------+-------+-------+-------+
  |       atomic int              |  <- single bus transaction, truly atomic - GOOD
  +-------+-------+-------+-------+

  Misaligned std::atomic<int> at 0x1001:
     +-------+-------+-------+-------+
     |       atomic int              |  <- may need two bus transactions - BAD
     +-------+-------+-------+-------+
     torn write possible: another thread reads half-old, half-new value

The C++11 Features That Actually Let You Control This

Before C++11, dealing with alignment was a mess of compiler-specific extensions. C++11 standardized it all.

Pre-C++11 (non-portable mess)      C++11 onwards (standardized)
──────────────────────────────     ──────────────────────────────────────
GCC:  __attribute__((aligned(N)))  alignof(T)          query alignment
MSVC: __declspec(align(N))         alignas(N)           force alignment
ICC:  __declspec(align(N))         std::align()         align inside buffer
(all different, all fragile)       std::aligned_storage typed raw buffer
──────────────────────────────     ──────────────────────────────────────
                                   C++17 adds: over-aligned operator new

alignof:

alignof(T) gives you the alignment requirement of type T. It's like sizeof but for alignment.

std::cout << alignof(int)    << "\n";  // 4
std::cout << alignof(double) << "\n";  // 8
std::cout << alignof(char)   << "\n";  // 1

You can also use it with a variable: alignof(myVar).

alignas:

alignas(N) lets you over-align a variable, a struct, or a struct member. You can only increase alignment, never decrease it.

alignas(16) float vec[4];  // 16-byte aligned, good for SIMD

struct alignas(64) CacheLinePadded {
    int data;
    // rest padded to 64 bytes
};

Without alignas:                  With alignas(16):

  float vec[4] at addr 0x05:        float vec[4] at addr 0x10:
  +----+----+----+----+             +----+----+----+----+
  | f0 | f1 | f2 | f3 |             | f0 | f1 | f2 | f3 |
  +----+----+----+----+             +----+----+----+----+
   ^--- not 16-aligned              ^--- 16-aligned (0x10 % 16 == 0)
        MOVUPS required - BAD             MOVAPS available - GOOD

The primary use cases are SIMD alignment and cache line alignment (more on that soon).

std::aligned_storage (deprecated in C++23 but worth knowing):

This was used to create raw storage with a specific alignment:

std::aligned_storage<sizeof(MyType), alignof(MyType)>::type buf;
MyType* p = new (&buf) MyType();

Mostly relevant in low-level allocator code or when you want a placement-new buffer on the stack with guaranteed alignment.

std::align:

Given a buffer, std::align finds the first aligned address within it for a given type. Useful when implementing custom allocators.

void* ptr = raw_buffer;
size_t space = sizeof(raw_buffer);
void* aligned = std::align(alignof(MyType), sizeof(MyType), ptr, space);

raw_buffer starts at 0x03, we need 4-byte alignment:

  0x03  0x04  0x05  0x06  0x07  0x08  0x09
  +-----+-----+-----+-----+-----+-----+-----+
  |     |     |     |     |     |     |     |
  +-----+-----+-----+-----+-----+-----+-----+
    ^--- raw start
          ^--- std::align returns this (first addr where addr % 4 == 0)
               advances ptr by 1, decreases space by 1

C++17: Over-Aligned new:

Before C++17 there was a quiet bug in the language: new and delete didn't know about alignas. If you wrote:

struct alignas(64) Foo { int x; };
Foo* p = new Foo;

The memory returned by operator new was only guaranteed to be aligned to __STDCPP_DEFAULT_NEW_ALIGNMENT__ (typically 8 or 16 bytes). Your alignas(64) request was silently ignored on the heap.

C++14 and earlier:

alignas(64) struct Foo { int x; };
  Foo* p = new Foo;
         |
         v
  operator new(sizeof(Foo))       ← no alignment argument passed
         |
         v
  returns 0x18 (8-byte aligned)   ← your alignas(64) silently ignored! - BAD

C++17 onwards:
Foo* p = new Foo;
         |
         v
  operator new(sizeof(Foo), std::align_val_t{64})   ← alignment passed 
         |
         v
  returns 0x40 (64-byte aligned)  ← alignas(64) respected on heap - GOOD

C++17 added overloads of operator new that take a std::align_val_t argument, and the compiler automatically passes the alignment when allocating over-aligned types.

If you’re doing anything with SIMD or cache-line-aware types on the heap, you need C++17 for this to work without writing a custom allocator.

Cache Lines: Where Alignment Goes from “Correctness” to “Performance”

The CPU doesn’t talk to RAM directly. It talks to its caches (L1, L2, L3). Memory is transferred between RAM and cache in units called cache lines — on virtually all modern x86 and ARM hardware, a cache line is 64 bytes.

  ┌─────────────────────────────────────────────────┐
  │  CPU DIE                                        │
  │                                                 │
  │   Core 0              Core 1                    │
  │  +----------+        +----------+               │
  │  | L1 cache |        | L1 cache |               │
  │  |  ~32KB   |        |  ~32KB   |               │
  │  +----+-----+        +----+-----+               │
  │       |                   |                     │
  │  +----+-----+        +----+-----+               │
  │  | L2 cache |        | L2 cache |               │
  │  |  ~256KB  |        |  ~256KB  |               │
  │  +----+-----+        +----+-----+               │
  │       └──────────┬────────┘                     │
  │             +----+-----+                        │
  │             | L3 cache |                        │
  │             |  ~8MB    |                        │
  │             +----+-----+                        │
  └──────────────────┼──────────────────────────────┘
                     │  64-byte cache lines travel up/down this path
  ┌──────────────────┴──────────────────────────────┐
  │                   RAM                           │
  └─────────────────────────────────────────────────┘

When your program accesses any byte in memory, the CPU loads the entire 64-byte chunk containing that byte into the cache. Subsequent accesses to nearby bytes are then free — they’re already in the cache. This is spatial locality, and most performance-oriented code is written to exploit it.

Alignment interacts with cache lines in two important ways.

False Sharing: Imagine two threads each updating their own independent counter, but those counters happen to live in the same struct close together:

struct Counters {
    int thread1_count;  // offset 0
    int thread2_count;  // offset 4
};

Both counters fit in the same 64-byte cache line. Here’s the problem:

One cache line = 64 bytes

  +------------------------------------------------------------------+
  | [thread1_count (4B)] [thread2_count (4B)] [ ... 56 bytes ... ]  |
  +------------------------------------------------------------------+
         ^                      ^
         Thread 1 writes here   Thread 2 writes here

  Step 1: Thread 1 writes thread1_count
          → entire cache line marked MODIFIED on Core 0
          → cache line INVALIDATED on Core 1

  Step 2: Thread 2 reads thread2_count
          → Core 1 sees line is invalid, must reload from Core 0 or RAM
          → even though thread2_count didn't change!

  Step 3: Thread 2 writes thread2_count
          → entire line INVALIDATED on Core 0

  Step 4: Thread 1 loops back, must reload...

  This ping-pong continues forever = FALSE SHARING
  Both threads slow each other down despite touching different data.

The fix is to pad each counter to occupy its own cache line:

struct alignas(64) Counter {
    int value;
    // alignas(64) forces sizeof(Counter) == 64
};

After padding with alignas(64):

  Cache line 0:
  +------------------------------------------------------------------+
  | [thread1_count (4B)] [ . . . . . . 60 bytes padding . . . . . ]  |
  +------------------------------------------------------------------+
    ^--- Thread 1 owns this line entirely. No other data here.

  Cache line 1:
  +------------------------------------------------------------------+
  | [thread2_count (4B)] [ . . . . . . 60 bytes padding . . . . . ]  |
  +------------------------------------------------------------------+
    ^--- Thread 2 owns this line entirely.

  Writes from Thread 1 never invalidate Thread 2's line. - GOOD
  5–10x speedup on tight counter loops is common.

Here’s a concrete example showing the difference:

#include <atomic>
#include <thread>
#include <iostream>
#include <chrono>

// Bad: both counters share a cache line
struct SharedCounters {
    std::atomic<long> a{0};
    std::atomic<long> b{0};
};

// Good: each counter on its own cache line
struct alignas(64) PaddedCounter {
    std::atomic<long> val{0};
};

struct SeparateCounters {
    PaddedCounter a;
    PaddedCounter b;
};

template<typename T>
long benchmark(T& counters) {
    auto start = std::chrono::high_resolution_clock::now();

    std::thread t1([&]() {
        for (int i = 0; i < 100'000'000; ++i)
            counters.a++;
    });
    std::thread t2([&]() {
        for (int i = 0; i < 100'000'000; ++i)
            counters.b++;
    });

    t1.join(); t2.join();
    auto end = std::chrono::high_resolution_clock::now();
    return std::chrono::duration_cast<std::chrono::milliseconds>(end - start).count();
}

In practice the padded version can be 5–10x faster depending on the hardware and contention level. The operations are identical. The difference is purely cache line ownership.

Struct Straddle: If a struct straddles a cache line boundary — meaning it starts near the end of one line and spills into the next — loading it requires two cache line reads instead of one.

Without alignment (struct starts 40 bytes into a cache line):

Cache line 0 (bytes 0–63)                 Cache line 1 (bytes 64–127)
+------------------------------------------+------------------------------------------+
| [......40 bytes.......][===MyStruct start | ===MyStruct end===][.....rest.........] |
+------------------------------------------+------------------------------------------+
                         ^--- struct begins here, straddles the boundary
                              two cache line loads required to read one struct - BAD

With alignas(64) on the array:

Cache line 0 (bytes 0–63)                 Cache line 1 (bytes 64–127)
+------------------------------------------+------------------------------------------+
| [=====MyStruct[0]=====][=MyStruct[1]===] | [=====MyStruct[2]=====][...rest......]   |
+------------------------------------------+------------------------------------------+
  ^--- each struct starts at a cache line    one load per struct - GOOD
         boundary (or stays within one line)

The fix:

alignas(64) MyStruct hot_data[1000];

Putting It Together: A Real-World Pattern

Here’s how these ideas combine in something like a game engine’s entity component system or any performance-sensitive data structure.

// Bad layout — padding waste + potential false sharing
struct ParticleSystem {
    bool  active;       // 1 byte
    double lifetime;    // 8 bytes
    bool  visible;      // 1 byte
    float x, y, z;      // 12 bytes
};

  Bad layout — 32 bytes total, 10 bytes wasted as padding:

  Offset:   0     1     2     3     4     5     6     7     8     9    10    11    12    13    14    15
            +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
            |  ac |/////|/////|/////|/////|/////|/////|/////|           lifetime (double, 8B)               |
            +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
             bool  <-----------  7 bytes padding  ----------->   double needs offset divisible by 8 ✓

  Offset:  16    17    18    19    20    21    22    23    24    25    26    27    28    29    30    31
           +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
           |  vi |/////|/////|/////|    x (float, 4B)      |    y (float, 4B)      |    z (float, 4B)      |
           +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
            bool  <-- 3 bytes pad-->   float needs offset divisible by 4, next is 20 ✓

  Fields:  active(1) + 7pad + lifetime(8) + visible(1) + 3pad + x(4) + y(4) + z(4) = 32 bytes
  Wasted:  7 + 3 = 10 bytes padding  →  31% of struct is dead space.
  At 1 million instances = ~10MB wasted just from field ordering.

// Better layout — sort by decreasing alignof
struct ParticleSystem {
    double lifetime;    // 8 bytes  (alignof = 8)
    float x, y, z;      // 12 bytes (alignof = 4)
    bool active;        // 1 byte   (alignof = 1)
    bool visible;       // 1 byte   (alignof = 1)
};

  Good layout — 24 bytes total, only 2 bytes wasted as tail padding:

  Offset:   0     1     2     3     4     5     6     7     8     9    10    11    12    13    14    15
            +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
            |           lifetime (double, 8B)               |    x (float, 4B)    |    y (float, 4B)        |
            +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
             no padding needed — double at offset 0 is already aligned ✓

  Offset:  16    17    18    19    20    21    22    23
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |    z (float, 4B)      |  ac |  vi |/////|/////|
           +-----+-----+-----+-----+-----+-----+-----+-----+
                                   bool  bool  <-2B tail->
                                               sizeof must be multiple of 8 (largest align) → rounds 22 → 24

  Fields:  lifetime(8) + x(4) + y(4) + z(4) + active(1) + visible(1) + 2pad = 24 bytes
  Wasted:  0 internal padding + 2 tail = 2 bytes  →  8% waste vs 31% before.
  At 1 million instances = ~2MB wasted instead of ~10MB. 8 bytes saved per instance.

For a particle system with 100,000 particles, the bad layout wastes about 800KB over the better layout (8 bytes saved per instance × 100,000 instances). More importantly, the better layout means more particles fit in cache at once, which improves iteration performance substantially.

Checking Your Structs:

A few things worth having in your toolbox:

// Check sizes and alignment at compile time
static_assert(sizeof(MyStruct) == 32, "unexpected size");
static_assert(alignof(MyStruct) == 8, "unexpected alignment");

// offsetof tells you where a field actually lives
#include <cstddef>
std::cout << offsetof(MyStruct, field_name) << "\n";

GCC and Clang also have -Wpadded which warns when the compiler inserts padding. It's noisy on large codebases but useful when auditing a hot data structure. Clang's sanitizers also have alignment checks via -fsanitize=alignment that will catch runtime misalignment.

Quick Reference

  ╔══════════════════════════════════════════════════════════════════════╗
  ║                     Alignment Cheat Sheet                            ║
  ╠═══════════════════════╦══════════════════════════════════════════════╣
  ║ alignof(T)            ║ query alignment requirement of T             ║
  ║ alignas(N)            ║ force alignment to N bytes (only increase)   ║
  ║ std::align()          ║ find aligned address inside a buffer         ║
  ║ offsetof(S, field)    ║ byte offset of field inside struct S         ║
  ║ static_assert         ║ verify size/alignment at compile time        ║
  ╠═══════════════════════╬══════════════════════════════════════════════╣
  ║ -Wpadded              ║ warn when compiler inserts padding           ║
  ║ -fsanitize=alignment  ║ catch misaligned access at runtime           ║
  ╠═══════════════════════╬══════════════════════════════════════════════╣
  ║ Field ordering rule   ║ largest alignof first → smallest last        ║
  ║ Cache line padding    ║ alignas(64) for shared mutable data          ║
  ║ Heap over-alignment   ║ C++17 required for alignas > 16 on heap      ║
  ╚═══════════════════════╩══════════════════════════════════════════════╝

Closing Thoughts

Avenger fans will understand this funny analogy: Thanos snapped his fingers and wiped out half the universe. Your struct’s padding bytes have been quietly doing the same to your RAM since day one — and unlike Thanos, they had no reason.

Remember: your CPU has been silently judging your struct layouts this whole time. Now you know how to make it proud.

If you’re serious about passing technical interviews, try PracHub. It helped me structure my preparation with advanced mock sessions. [**Check it out here**] and start practicing. (Disclosure: This is an affiliate link).

Found this article helpful? Clap 👏 and follow for more C++ and system programming content.