C++20 std::span: A Modern Guide to Type-Safe Memory Views
Learn how to replace raw pointers and sizes with std::span to create flexible, high-performance APIs without the overhead
In the beginning, there was
T*andsize_t. And the programmer saw it, and it was... a bug waiting to happen." — Every C++ developer, probably
What is std::span?
std::span is a lightweight, non-owning view over a contiguous sequence of objects. Think of it as a {pointer, length} pair bundled into a type-safe, STL-friendly package.
It lives in the <span> header. That's it. That's the whole dependency.
The mental model is simple:
┌──────────────────────────────────────────────────────────┐
│ YOUR ACTUAL DATA │
│ (array, vector, C-array, alloc'd memory, whatever) │
│ │
│ ┌─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┐ │
│ │ 10 │ 20 │ 30 │ 40 │ 50 │ 60 │ 70 │ 80 │ │
│ └─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┘ │
│ ▲ │
│ │ │
│ ┌────┴──────────────┐ │
│ │ std::span │ │
│ │ ┌──────────────┐ │ "I don't OWN this data. │
│ │ │ ptr = 0xABC │ │ I just LOOK at it." │
│ │ │ size = 8 │ │ │
│ │ └──────────────┘ │ │
│ └───────────────────┘ │
└──────────────────────────────────────────────────────────┘The key insight: std::span is to std::vector what std::string_view is to std::string. It says: "I know there's data over there. I'll point at it and tell you how long it is. Copying it, allocating it, freeing it — that's your problem, not mine."
The Problem std::span Solves
Let’s take a trip down memory lane. You need to write a function that processes some integers. How many signatures do you write ?
// The "I've been writing C since 1989" way
void process(int* data, size_t length);
// The "I read a C++ book once" way
void process(std::vector<int>& vec);
// The "I'm const-correct and proud" way
void process(const std::vector<int>& vec);
// The "I also use arrays sometimes" way
void process(std::array<int, 10>& arr);
// The "Template everything!" way
template<typename Container>
void process(const Container& c);
// The "I give up, just take iterators" way
template<typename Iter>
void process(Iter begin, Iter end);Six different signatures for essentially the same operation. That’s not an overload set — that’s a cry for help.
Enter std::span:
#include <span>
// ONE function to rule them all
void process(std::span<const int> data);This single signature accepts std::vector<int>, std::array<int, N>, C-style arrays, raw pointer + size pairs, and any other contiguous container. One signature. Zero copies. Maximum flexibility.
Have a look at the below example for more clarity:
#include <iostream>
#include <span>
#include <vector>
#include <array>
// This ONE function works with everything contiguous
void print_elements(std::span<const int> data) {
std::cout << "[ ";
for (const auto& elem : data) {
std::cout << elem << " ";
}
std::cout << "] (size: " << data.size() << ")\n";
}
int main() {
// 1. From a std::vector
std::vector<int> vec = {1, 2, 3, 4, 5};
print_elements(vec); // [ 1 2 3 4 5 ] (size: 5)
// 2. From a std::array
std::array<int, 4> arr = {10, 20, 30, 40};
print_elements(arr); // [ 10 20 30 40 ] (size: 4)
// 3. From a C-style array (yes, even that old relic)
int c_arr[] = {100, 200, 300};
print_elements(c_arr); // [ 100 200 300 ] (size: 3)
// 4. From pointer + size (for the C interop folks)
int* ptr = vec.data();
print_elements({ptr, 3}); // [ 1 2 3 ] (size: 3)
// 5. From an initializer list... just kidding.
// That doesn't work. The data dies too fast.
// Nice try though.
return 0;
}Note:
Theconstinstd::span<const int>means "I promise not to modify your data through this view." Drop theconstif you want to mutate. We'll get to that.
Static vs Dynamic Extent — Choose Your Fighter
This is where std::span gets interesting. It comes in two flavors.
Dynamic Extent (the default):
std::span<int> // same as std::span<int, std::dynamic_extent>Size is determined at runtime. The span stores both a pointer and a size.
Static Extent:
std::span<int, 5> // "I ALWAYS point to exactly 5 ints"Size is baked into the type at compile time. The span only stores a pointer.
DYNAMIC EXTENT (runtime size)
std::span<int> s = vec;
┌──────────────────┬──────────────────┐
│ T* pointer │ size_t extent │ ← 16 bytes on 64-bit
└──────────────────┴──────────────────┘
STATIC EXTENT (compile-time size)
std::span<int, 5> s = arr;
┌──────────────────┐
│ T* pointer │ ← Only 8 bytes! Size lives in the type.
└──────────────────┘When should you use which ?
// Dynamic: when you don't know (or care about) the size at compile time
void process_any(std::span<const int> data) {
for (auto val : data) { /* ... */ }
}
// Static: when the size IS the contract
void process_rgb_pixel(std::span<const uint8_t, 3> pixel) {
// Pass 4 bytes? Compile error. Beautiful.
auto r = pixel[0];
auto g = pixel[1];
auto b = pixel[2];
}
int main() {
std::array<uint8_t, 3> red = {255, 0, 0};
process_rgb_pixel(red); // Fine
std::array<uint8_t, 4> rgba = {255, 0, 0, 128};
// process_rgb_pixel(rgba); // Won't compile! Size mismatch.
// Static → dynamic is always fine (you're just "forgetting" info)
std::span<const uint8_t> dynamic_view = red;
// Dynamic → static requires an explicit step
auto fixed = dynamic_view.first<3>(); // Returns span<const uint8_t, 3>
}Rule of thumb:
Use dynamic extent in public APIs for flexibility.
Use static extent in performance-critical internals where the size is fixed and known.
Everything You Can Do With span
std::span provides a surprisingly rich interface. Here's the full tour.
Construction Apis:
// Default: empty span
std::span<int> empty; // ptr=nullptr, size=0
// From C-array
int arr[5] = {1, 2, 3, 4, 5};
std::span<int> s1(arr); // deduces size = 5
std::span<int> s2(arr, 3); // first 3 elements only
// From pointer + size
std::span<int> s3(arr + 1, 3); // {2, 3, 4}
// From pointer + pointer (iterator pair)
std::span<int> s4(arr + 1, arr + 4); // {2, 3, 4}
// From std::array and std::vector
std::array<int, 4> stdarr = {10, 20, 30, 40};
std::span<int> s5(stdarr);
std::vector<int> vec = {100, 200, 300};
std::span<int> s6(vec);
// CTAD (Class Template Argument Deduction) works!
std::span s7(vec); // deduces std::span<int> (dynamic)
std::span s8(arr); // deduces std::span<int, 5> (static!)
std::span s9(stdarr); // deduces std::span<int, 4> (static!)CTAD surprise:
std::span s(arr)deduces a static extent from C-arrays andstd::array, but a dynamic extent fromstd::vector. The compiler knows the array size at compile time — it doesn't know the vector's. This makes sense once you see it.
Element Access:
std::vector<int> vec = {10, 20, 30, 40, 50};
std::span<int> s(vec);
s[0]; // 10 — no bounds checking, just like arrays
s.front(); // 10
s.back(); // 50
s.data(); // raw pointer to first element
// Modification through a non-const span modifies the ORIGINAL data
s[2] = 999; // vec is now {10, 20, 999, 40, 50}
// No copy happened. The span reached right in.Size and State:
std::span<int> s(vec);
s.size(); // number of elements
s.size_bytes(); // size in bytes (size() * sizeof(T))
s.empty(); // true if size == 0Iteration:
std::vector<int> vec = {5, 3, 1, 4, 2};
std::span<int> s(vec);
// Range-based for (the civilized way)
for (const auto& val : s) { /* ... */ }
// Works with <algorithm>
std::sort(s.begin(), s.end()); // sorts through the span
std::ranges::sort(s); // even cleaner
// vec is now {1, 2, 3, 4, 5} — sorted in place, zero copiesSubviews: first, last, and subspan
This is where std::span really earns its keep. You can slice it without copying a single byte.
Original span:
┌─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┐
│ 10 │ 20 │ 30 │ 40 │ 50 │ 60 │ 70 │ 80 │
└─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┘
[0] [1] [2] [3] [4] [5] [6] [7]
.first(3) ──> [ 10 | 20 | 30 ]
.last(3) ──> [ 60 | 70 | 80 ]
.subspan(2, 4) ──> [ 30 | 40 | 50 | 60 ]
.subspan(5) ──> [ 60 | 70 | 80 ]Each operation comes in two forms. Runtime (dynamic) versions take function parameters and return dynamic-extent spans:
auto f = s.first<3>(); // type: std::span<const int, 3>
auto l = s.last<3>(); // type: std::span<const int, 3>
auto sub = s.subspan<2, 4>(); // type: std::span<const int, 4>Why does this matter?
Static-extent spans give the compiler more to work with — loop unrolling, SIMD vectorization, fewer branches. It’s not just syntax sugar.
Lets have a look at a practical example of a Parsing a network packet:
#include <span>
#include <cstdint>
// Parse a fixed-size header, return a view of the payload.
// No copies. No allocations. Just pointer arithmetic in a nice suit.
std::span<const std::byte> parse_packet(std::span<const std::byte> raw_data) {
auto header = raw_data.first<4>(); // fixed 4-byte header
auto payload = raw_data.subspan(4); // everything after
return payload;
}What’s Actually Happening Under the Hood:
DYNAMIC EXTENT: std::span<int>
─────────────────────────────
The span object (on the stack):
┌──────────────────┬──────────────────┐
│ T* data_ptr │ size_t size │ = 16 bytes (64-bit)
│ 0x7FFE'1234 │ 5 │
└────────┬─────────┴──────────────────┘
│
▼ (points to the actual data, owned by someone else)
┌─────┬─────┬─────┬─────┬─────┐
│ 10 │ 20 │ 30 │ 40 │ 50 │
└─────┴─────┴─────┴─────┴─────┘
STATIC EXTENT: std::span<int, 5>
─────────────────────────────────
The span object:
┌──────────────────┐
│ T* data_ptr │ = 8 bytes (the size lives in the TYPE)
│ 0x7FFE'1234 │
└────────┬─────────┘
▼
┌─────┬─────┬─────┬─────┬─────┐
│ 10 │ 20 │ 30 │ 40 │ 50 │
└─────┴─────┴─────┴─────┴─────┘For reference, here’s how std::span stacks up against other types:
std::spanis as cheap as a raw pointer+size pair, with the ergonomics of a container. Zero-cost abstraction in the truest sense.
Performance and Memory Tradeoffs
Alright, let’s talk performance. This is the section that justifies std::span's existence to your skeptical tech lead.
Get Sagar’s stories in your inbox
Join Medium for free to get updates from this writer.
Zero-Copy Everything:
#include <span>
#include <vector>
// This function accepts a view. ZERO bytes copied.
double average(std::span<const double> values) {
double sum = 0.0;
for (auto v : values) sum += v;
return values.empty() ? 0.0 : sum / values.size();
}
int main() {
std::vector<double> million_doubles(1'000'000, 42.0);
// Passing by span: ~16 bytes on the stack. That's it.
// No copy of the million doubles. Not even a shared_ptr dance.
double avg = average(million_doubles);
// Slicing: also zero-copy
double first_half_avg = average(
std::span(million_doubles).first(500'000)
);
}Here’s what the passing cost looks like:
Method | Bytes Copied | Allocations
──────────────────────────┼─────────────────┼────────────────
vector<int> (by value) | N * 4 + 24 | 1 heap alloc
const vector<int>& | 8 (reference) | 0
span<const int> | 16 (ptr + size) | 0
span<const int, 100> | 8 (ptr only!) | 0
int*, size_t | 16 | 0
* span and const& are similar in cost, but span is more
flexible — it doesn't require a specific container type.Static Extent Enables Compiler Optimizations So Static Extent Can Actually Be Faster:
#include <span>
#include <numeric>
// The compiler knows there are exactly 4 doubles.
// It can:
// - Unroll the loop completely
// - Use SIMD instructions (e.g., 256-bit AVX for 4 doubles)
// - Eliminate bounds-related branches
double sum_4(std::span<const double, 4> values) {
return values[0] + values[1] + values[2] + values[3];
}
// The compiler doesn't know the size.
// It has to generate a general loop.
double sum_n(std::span<const double> values) {
double total = 0.0;
for (auto v : values) total += v;
return total;
} OPTIMIZATION POTENTIAL
Static extent: ==================== HIGH
- Loop unrolling
- SIMD vectorization
- Dead code elimination
- Compile-time size checks
Dynamic extent: ==================== MODERATE
- Standard loop optimization
- Still zero-copy
- Comparable to const& performance
Pass by value: === LOW (dominated by copy cost)Real-world benchmark numbers (x86–64, GCC/Clang -O2, summing 1000 ints, 10M iterations):
Method | Time (ns) | Relative
────────────────────────────┼─────────────┼──────────────
raw pointer + size | ~310 ns | baseline
span<const int> | ~310 ns | ~1.00x
const vector<int>& | ~315 ns | ~1.02x
span<const int, 1000> | ~285 ns | ~0.92x (faster!)
vector<int> (by value!) | ~1800 ns | ~5.8x (ouch)
Notes:
- span matches raw pointer performance (zero overhead)
- Static extent can be FASTER due to compiler optimizations
- Pass-by-value copies are murderBottom line:
std::spanhas zero overhead compared to raw pointers.
Static extent variants can actually be faster than anything else because the compiler gets more information to work with.
The Honest Tradeoffs
Nothing in engineering is free. Here’s the honest truth:
TRADEOFF ANALYSIS
BENEFITS | COSTS / RISKS
──────────────────────────────────┼──────────────────────────────
Zero-copy, zero-allocation | No ownership = dangling
| reference risk
Type-safe (unlike ptr+size) | No bounds checking by
| default (operator[] is UB)
Works with any contiguous | Only works with CONTIGUOUS
container | memory (no list, deque, etc.)
Tiny object size (8-16 bytes) | Can't extend/resize the
| underlying data
Static extent -> optimizations | Static extent -> less
| flexible APIs
Replaces (T*, size) C idiom | Requires C++20
Implicit conversions from | Implicit conversions can
vector, array, etc. | sometimes be surprisingKnown Failure Modes — Things you need to be careful when working with std::span
std::span is sharp. Respect the blade. Below are few things to watch out:
- Dangling Spans (The Big One):
std::span does not own data. If the source dies, your span becomes garbage.
// DANGER: returning a span to a local
std::span<int> create_and_return() {
std::vector<int> local_vec = {1, 2, 3};
return std::span<int>(local_vec); // DANGLING!
// local_vec destroyed here. The span points to freed memory.
}
// DANGER: vector reallocation invalidates spans
void reallocation_trap() {
std::vector<int> vec = {1, 2, 3};
std::span<int> s = vec;
vec.push_back(4); // May reallocate!
// s might now point to freed memory.
// s[0] = 42; // Potential use-after-free.
}The timeline of doom:
t=0: vector created t=1: span created t=2: vector destroyed
at 0xABCD pointing to 0xABCD memory freed!
[vector] → [1,2,3] [span] → [1,2,3] [span] → [????]
GARBAGE!2. No Bounds Checking:
std::vector<int> vec = {1, 2, 3};
std::span<int> s = vec;
s[100] = 42; // UB. No exception. No crash (maybe). Just corruption.
// std::span does NOT have .at() like vector.The committee chose zero overhead over safety. Every access is a branch you didn’t pay for — until you access out of bounds. Check size() yourself before indexing.
Why no .at()? The C++ committee decided std::span should be a zero-overhead abstraction. Bounds checking would add a branch on every access. If you want safety, use a library like GSL's gsl::span, which does offer checked access.
3. Non-Const Span Modifies the Original:
void sneaky_modification(std::span<int> s) {
s[0] = 999; // This modifies the ORIGINAL data!
}
int main() {
std::vector<int> vec = {1, 2, 3};
sneaky_modification(vec);
// vec is now {999, 2, 3}
//
// If this surprises you, remember: span is a VIEW,
// not a copy. Use span<const int> to prevent this.
}4. Initializer Lists Don’t Work:
void process(std::span<const int> s);
// process({1, 2, 3}); // Compile error!
// The initializer_list's backing array is temporary —
// it's destroyed before the function can use it.
// Workaround:
const auto data = std::array{1, 2, 3};
process(data); // Works fine.5. Byte Views (std::as_bytes):
std::vector<int> vec = {1, 2, 3, 4};
// Read-only byte view of the vector's raw memory
auto bytes = std::as_bytes(std::span(vec));
// type: std::span<const std::byte>
// size: 16 (4 ints × 4 bytes each)
// Writable byte view — useful for serialization/memcpy
auto writable = std::as_writable_bytes(std::span(vec));
// type: std::span<std::byte>
// Be careful with endianness and alignment.
The “Should I Use std::span?" Flowchart
Do I need to OWN the data? (store, resize, free it)
└─ YES → Use vector / array
Is the data CONTIGUOUS in memory?
└─ NO → Use iterators or ranges
Am I passing to a function that just reads or writes it?
└─ YES → USE SPAN!
span<const T> → read-only
span<T> → read-write
Am I storing it as a member with a guaranteed lifetime?
└─ YES → span is OK, but document the contract loudly
└─ NO → Don't use span. Copy the data, or use shared_ptr.GOLDEN RULES:
- span does NOT own data — don’t let it outlive the source
- No bounds checking on operator[] — check size() yourself
- Use span<const T> for read-only parameters (default to this)
- Don’t modify the source container while a span refers to it
Closing Thoughts
std::span isn't exciting. It's a pointer and a size with good manners — and that's exactly the point.
The best abstractions don’t make you think. They just quietly eliminate a whole category of mistakes while you’re busy solving the actual problem. This is one of them.
Default to span<const T>, watch your lifetimes, and go delete some overloads. You've got better things to worry about.
Written with love and far too much coffee. Feedbacks are welcome !!!
If this clicked:
Clap 👏 so fewer people ship (ptr, len) bugs to production
Follow for more C++ patterns that make your profiler boring
And tell me — what’s the most cursed memory API you’ve had to maintain?
