C++ string_view and span: Avoid Dangling Views

A view is a window onto existing data

A string owns its character sequence and a vector owns its elements. Sometimes a function only needs to read part or all of that existing data during a call. Making another owning copy may not be necessary. A view describes access to an existing range instead. Picture a window over a row of values: the window tells you which values to see, but the window does not keep the underlying row alive.

std::string_view describes a character range. std::span<T> describes a contiguous range of T elements and is available in C++20. Both carry range information that is more useful than a bare pointer alone. Neither is a lifetime manager. Copying the view copies its description, not the underlying owned data, and it does not normally extend the lifetime of the object that supplies those characters or elements.

Ask three questions when you see a view: who owns this data, how long will that owner remain valid, and will anything change its storage before the view is used? These questions are easier to answer when a function borrows a range only for the duration of a call. They become harder when a view is stored in a long-lived object or returned from a function whose local owner is about to disappear.

string_view is not another editable string

The first example creates an owning string containing hello. whole observes all five characters. Calling whole.substr(1, 3) creates another view of the three characters starting at index one, so it displays ell. It does not change owner or create another owned string containing those letters. The original string remains alive and unchanged until after both output operations, which makes the borrowed access valid.

A string_view lets you read characters but not change them through the view. It also does not promise a null terminator at the end of its selected range. Do not pass view.data() to an interface that expects a zero-terminated string unless that interface's requirements are actually satisfied. Stream output understands the view's length; an unrelated C-style text function may not. Knowing the selected length matters even when the displayed text looks ordinary.

For this course's text examples, positions and lengths count char units, commonly UTF-8 bytes in real files, not user-perceived letters. Slicing bytes can split a multi-byte character. This lesson teaches ownership and access, not Unicode normalization or a safe text-editor cursor. Use a suitable text-processing library when the actual task requires grapheme-aware editing instead of treating every byte index as a human character position.

• owner stores the characters.
• whole records access to the owner's full range.
• middle records a smaller range, starting after h.
• Output happens before owner is destroyed or its storage can change.

span describes a sequence; its element type controls writing

A span can be built over a suitable array or vector of contiguous elements. A function taking std::span<const int> can read integers from either source without demanding a particular owning container type. The size travels with the access range. That is a useful interface when a calculation needs a sequence now but should not take ownership, resize the container or keep a hidden copy for later.

Read the type carefully. const std::span<int> makes the view handle const, but its int elements can still be writable through that handle. std::span<const int> gives read-only access to the elements. Const on the wrapper is not automatically deep const on everything it describes. Our sum function uses span<const int> because adding readings does not require permission to change them.

A view reflects valid changes made to the same underlying elements; it is not a frozen snapshot. The span example changes an array element through its owner and then observes the new value through a read-only view. The array's storage and lifetime have not changed. This is different from growing a vector so that it reallocates: a view into its former storage would no longer provide valid access. Rebuild a view after such a structural change.

Return ownership when the data must survive the function

A common mistake is to create a local string and return a string_view referring to it. When the function returns, that local string is destroyed, leaving the view without a valid owner. The view may still have a nonzero size and a non-null data pointer. Neither observation makes the characters safe to read. We describe this error rather than running it, because undefined behavior has no trustworthy expected transcript.

One repair is to return an owning std::string. The caller keeps that returned value alive and may create a temporary view of it during later work. Another design can accept an existing owner by reference and return a view into that owner, but then the caller must respect the owner's lifetime. Choose based on who needs the data, not on a wish to make every function return a small view type.

Bounds also need care. In C++20, unchecked span indexing does not provide an automatic exception for every invalid index. Check the selected range before reading an element, and handle an empty span with an empty traversal. Do not use front or index zero merely because the view object itself exists. Ownership, lifetime and bounds are three separate facts; a safe design establishes all the ones its operations require.

Create the views after collection, then finish using them before owners end

The lab reads a label line of one through forty bytes, a count from zero through five, and that many whole integer reading lines from minus one hundred through one hundred. The displayed label is the part before the first colon, or the whole line if no colon exists. That prefix must contain something other than ordinary spaces. These are narrow byte-level rules; they do not claim to trim all whitespace or normalize Unicode.

Keep the owning string and vector in main. Finish all vector push_back operations before creating a span of its elements. Make a string_view of the label prefix while the string is still alive and unchanged. Pass span<const int> to a pure total function, then print Label, Count and Total before leaving main. At most five bounded values keep the sum within minus five hundred through five hundred, including the empty total of zero.

Test a label with and without a colon, an empty prefix, the maximum label length, an empty reading sequence and malformed required readings. Do not append to the vector or replace the owning string while using their views. As a repair exercise, explain what would go wrong if the label owner were created in a helper and destroyed before reporting. Choose an owning return value or a caller-owned argument rather than hoping the old bytes remain readable.