Strings, Small String Optimization (SSO), string_view & span

Calling malloc/new for every string is a major performance bottleneck: it fragments memory and stalls threads on allocator locks. Because most strings (usernames, symbols, error codes) are short, C++ uses Small String Optimization (SSO):

The Dual-Mode Union: Inside std::string, a union overlaps stack storage with heap metadata:

// Conceptual layout in GCC libstdc++ (64-bit, 32 bytes):
class string {
    char* _M_dataplus;       // 8B: points to heap OR points inside _M_local_buf
    size_t _M_string_length; // 8B: current length
    union {
        char _M_local_buf[16];        // 16B: stores up to 15 chars + '\0'
        size_t _M_allocated_capacity; // 8B: active when spilled to heap
    };
};

The Two Operating States:

1. Pocket Mode (length <= 15): Characters live inside _M_local_buf. s.data() points directly into the string's own stack frame. Zero heap allocations occur!
2. Spill Mode (length >= 16): Allocates an external buffer on the heap. _M_dataplus points to that heap memory, and _M_allocated_capacity tracks the buffer size.

Proving SSO with Pointer Arithmetic: If s.data() falls within the address range [&s, &s + 1), the character buffer resides physically inside the stack object itself!

Before C++17, slicing a string with s.substr() forced a new heap allocation and byte copy.

std::string_view acts as a lightweight, non-owning window into existing characters:

• Exact 16-byte Footprint: Holds only const char* ptr_ (8 bytes) and size_t len_ (8 bytes).
• O(1) Substrings: sv.substr(offset, count) simply evaluates ptr_ + offset and adjusts length. Zero heap allocations, zero character copies.
• Pass By Value: Always pass std::string_view by value, never by const&. On 64-bit ABIs, 16-byte structs pass directly inside two CPU registers (rsi, rdx), completely avoiding memory indirection.

std::string_view borrows memory without owning it, introducing two high-frequency interview bugs:

Trap 1: Dangling Reference to a Temporary String:

// DEADLY BUG: temporary string destroyed at the semicolon!
std::string_view sv = std::string("user_") + id; // sv points to dead memory!

The temporary std::string dies the instant the line finishes executing. The string_view now points to garbage heap memory.

Trap 2: Missing Null Terminator on Substrings:

• std::string::c_str() is guaranteed to end in \0.
• std::string_view is NOT null-terminated! Slicing sv.substr(0, 5) points to the first 5 characters inside a larger buffer with no \0 after character 5.
• Passing sv.data() to C APIs (printf("%s"), fopen(), strlen()) causes the C function to read past the slice into adjacent memory until finding a random \0, triggering buffer over-reads and data leaks!
• Fix: Convert to std::string(sv) or copy into a null-terminated buffer before crossing C API boundaries.

While std::string_view is specialized for characters, C++20 std::span<T> creates a non-owning window over any contiguous sequence of typed elements:

• 16-byte Layout: Stores a pointer T* data_ (8 bytes) and element count size_t size_ (8 bytes).
• Universal Parameter Target: Replaces cumbersome C-style pointer-plus-size pairs (T* arr, size_t n) and works seamlessly with:
  • std::vector<T>
  • std::array<T, N>
  • Stack C-arrays T arr[N]
• Read & Write Access: Unlike std::string_view (which is strictly read-only), std::span<T> allows direct in-place mutation of caller elements. Use std::span<const T> for read-only guarantees.

Choosing the right string parameter signature is a common staff-level interview prompt:

1. Accept std::string_view by value:
   • Best for read-only inspection or substring tokenization.
   • Accepts string literals ("literal"), std::string, and char buffers with zero temporary heap allocations.
2. Accept const std::string&:
   • Use only when the function must pass the string directly into a legacy C API requiring a guaranteed null-terminated const char* via .c_str().
3. Accept std::string by value + std::move:
   • Use when the function intends to keep ownership (e.g. constructor initializing a member variable).
   • Rvalues (std::string(...) or std::move(...)) move their heap buffer directly in O(1) with zero copy overhead.