Question
std::string_view vs std::string: Ownership vs Performance Trade‑off
Ira Maple
0 reputation · 08 Oct 2023, 12:53 UTC
77.2K views1
Loading…
0 reputation · 08 Oct 2023, 12:53 UTC
Design a function that accepts textual data while balancing zero‑copy performance with lifetime safety. The decision centers on whether to expose std::string_view for read‑only consumption or require std::string to enforce ownership.
std::string_view avoid allocations but risk dangling references if the caller’s buffer is destroyed or mutated during the call.std::string overload triggers construction of a temporary, incurring an allocation or move, which can be costly in high‑throughput or embedded contexts.Should read‑only APIs default to std::string_view to eliminate unnecessary copies, or should they default to std::string to guarantee safety against dangling references?
std::string_view for a function that never stores the incoming data?std::string_view references in public APIs?std::string and the potential risk of undefined behavior with std::string_view?31775 reputation · 09 Oct 2023, 00:04 UTC
For functions that only read data and do not store it beyond the scope of the call, std::string_view should be the default choice. It eliminates unnecessary heap allocations when passing string literals or substrings, providing a lightweight, non-owning reference to a character sequence.
The choice between these types centers on the balance between memory allocation overhead and lifetime guarantees:
cppconst std::string& is safe but triggers a heap allocation if a string literal ("example") is passed, as a temporary std::string must be constructed.std::string, or a character array.| Operation | std::string (const ref) | std::string_view |
|---|---|---|
| Passing Literal | Allocation (Temporary) | Zero-copy |
| Slicing (substr) | O(N) Allocation/Copy | O(1) Pointer Adjustment |
| Ownership | Guaranteed | Dependent on Caller |
Use std::string_view when the function follows these criteria:
\0), as string_view does not guarantee null-termination.To prevent dangling references in public APIs, apply these constraints:
std::string_view as a class member unless the class is a short-lived utility (like a parser) and the lifetime of the source data is strictly managed.std::string_view but explicitly convert it to std::string using the std::string(view) constructor at the point of storage.To quantify the performance gain or detect lifetime errors, use the following approach:
-fsanitize=address) to catch use-after-free errors caused by temporary strings passed to views.const std::string& vs std::string_view when processing thousands of small string literals.Missing Diagnostic: Does your API need to interface with legacy C functions (e.g., fopen, printf)? If so, std::string_view may introduce bugs due to the lack of a guaranteed null-terminator.
Use comments to ask for clarification. Post a solution as an answer.
31,775 reputation · 09 Oct 2023, 00:43 UTC
When a function takes std::string_view by value, the caller’s buffer must stay valid for the entire call. For string literals this guarantee is automatic because they have static storage duration, so no dangling risk arises. However, if the argument is a temporary std::string (e.g., from a function returning std::string), binding it to a std::string_view does not extend the temporary’s lifetime; the view becomes dangling once the temporary is destroyed at the end of the full‑expression. In contrast, taking the argument by const std::string& does extend the lifetime of the temporary to the reference’s scope, but the temporary still incurs a construction cost (allocation or small‑string‑optimization copy). Therefore, a safe pattern is to overload: void foo(std::string_view) for read‑only use with documented precondition that the caller guarantees buffer lifetime, and void foo(std::string) (by value) when ownership is needed or when the caller prefers to avoid lifetime concerns.