Mastering std::span and std::string_view in Modern C++

In modern C++, performance and safety are paramount. Two powerful tools that help achieve both are std::span (C++20) and std::string_view (C++17). These non-owning views allow you to pass around references to contiguous data without copying, reducing allocations and improving cache locality. They also provide a uniform interface for arrays, std::vector, std::string, and even raw pointers with a size. This tutorial will dive deep into their usage, common pitfalls, and production-ready patterns. By the end, you'll be able to refactor your code to be more efficient and expressive, avoiding unnecessary copies and buffer overruns.

What is std::string_view?

std::string_view, introduced in C++17, is a non-owning reference to a contiguous sequence of characters. It typically consists of a pointer to the first character and a size. It does not allocate memory and does not manage the lifetime of the underlying string. Use it to pass string data to functions without copying, especially when you only need to read the data. It works with std::string, const char*, and even substrings. However, be cautious: std::string_view is not null-terminated, so functions expecting a C-string may misbehave. Also, ensure the underlying data outlives the view.

#include <iostream>
#include <string_view>

void print_length(std::string_view sv) {
    std::cout << "Length: " << sv.size() << '\n';
}

int main() {
    std::string s = "Hello, World!";
    const char* cstr = "C-string";
    
    print_length(s);          // from std::string
    print_length(cstr);       // from const char*
    print_length("Literal"); // from string literal
    
    std::string_view sub = s.substr(0, 5); // view of first 5 chars
    std::cout << sub << '\n'; // prints "Hello"
    return 0;
}

What is std::span?

std::span, introduced in C++20, is a non-owning view over a contiguous sequence of objects. It is essentially a pointer and a size, but with a rich interface similar to std::vector or std::array. It can be constructed from arrays, std::vector, std::array, or raw pointer+size. std::span provides bounds-checked access via .at() and supports iteration, subviews, and more. It is ideal for writing functions that operate on contiguous data without being templated on the container type. However, like std::string_view, it does not own the data, so lifetime management is critical.

#include <iostream>
#include <span>
#include <vector>

void print_sum(std::span<const int> sp) {
    int sum = 0;
    for (int x : sp) sum += x;
    std::cout << "Sum: " << sum << '\n';
}

int main() {
    int arr[] = {1, 2, 3, 4, 5};
    std::vector<int> vec = {10, 20, 30};
    
    print_sum(arr);       // from C-array
    print_sum(vec);       // from std::vector
    print_sum({1,2,3});   // from initializer list
    
    std::span<int> sp(arr);
    auto first3 = sp.first(3); // subspan
    for (int x : first3) std::cout << x << ' ';
    return 0;
}

Common Use Cases and Best Practices

Both std::span and std::string_view shine in function parameters. Instead of overloading for std::string, const char*, and std::string_view, just use std::string_view. Similarly, for arrays, use std::span. They also enable efficient substring and subarray operations without copying. Best practices: pass by value (they are cheap to copy), use const whenever possible, and never store them as class members unless you are certain the underlying data outlives the object. For APIs that need to modify data, consider std::span with mutable elements.

#include <iostream>
#include <string_view>
#include <span>
#include <algorithm>

// Good: accepts any string-like type
void to_upper(std::span<char> sp) {
    for (char& c : sp) c = std::toupper(c);
}

// Good: read-only view
void print(std::string_view sv) {
    std::cout << sv << '\n';
}

int main() {
    char arr[] = "hello";
    to_upper(arr);
    print(arr); // prints "HELLO"
    
    std::string s = "world";
    to_upper(s);
    print(s); // prints "WORLD"
    return 0;
}

Lifetime and Safety Considerations

The most critical aspect of using views is ensuring the underlying data remains valid. A common mistake is returning a std::string_view from a function that creates a temporary std::string. Similarly, storing a std::span that points to a local array is dangerous. Always think about ownership. Use tools like AddressSanitizer and Valgrind to detect dangling references. Additionally, std::string_view is not null-terminated; if you need a C-string, copy to std::string first. For std::span, be aware that the size is not checked by default; use .at() for bounds checking or enable debug iterators.

#include <iostream>
#include <string_view>

std::string_view get_subview() {
    std::string s = "temporary";
    return s; // DANGER: s is destroyed, view dangles
}

int main() {
    std::string_view sv = get_subview();
    std::cout << sv << '\n'; // undefined behavior
    return 0;
}

Performance Implications

std::span and std::string_view are zero-overhead abstractions: they are essentially a pointer and a size. Passing them by value is cheap (two registers or stack slots). They eliminate copies of the underlying data, which reduces allocations and memory bandwidth. However, they can introduce subtle performance issues if used incorrectly. For example, iterating over a std::span may be slower than a raw pointer if the compiler cannot optimize away bounds checks (in debug mode). Also, constructing a std::string_view from a std::string is O(1), but constructing from a const char* requires a call to strlen (O(n)). To avoid that, use the two-argument constructor if you know the length.

#include <iostream>
#include <string_view>
#include <chrono>

int main() {
    const char* large = "..."; // imagine a large string
    auto start = std::chrono::steady_clock::now();
    for (int i = 0; i < 1000000; ++i) {
        std::string_view sv(large); // calls strlen each time
    }
    auto end = std::chrono::steady_clock::now();
    std::cout << "Time: " << std::chrono::duration_cast<std::chrono::milliseconds>(end-start).count() << "ms\n";
    return 0;
}

Interoperability with Legacy Code and C APIs

Many C APIs expect a pointer and a size. std::span and std::string_view can bridge the gap: use .data() and .size() to pass to C functions. However, be careful: std::string_view.data() is not guaranteed to be null-terminated, so if the C function expects a null-terminated string, you must copy to a std::string or ensure the view is from a null-terminated source. For std::span, .data() gives a pointer to the first element. You can also construct a std::span from a pointer and size returned by a C API. This makes views excellent for wrapping legacy interfaces safely.

#include <iostream>
#include <span>
#include <cstring>

// C-style function that expects a buffer and size
void process_buffer(const char* data, size_t size) {
    std::cout << "Processing " << size << " bytes\n";
}

void modern_process(std::string_view sv) {
    // Safe: pass data and size to C function
    process_buffer(sv.data(), sv.size());
}

int main() {
    std::string s = "Hello";
    modern_process(s);
    
    // Construct span from C array
    int arr[] = {1,2,3};
    std::span<int> sp(arr);
    // Pass to C function expecting int* and size
    some_c_function(sp.data(), sp.size());
    return 0;
}