Header Reference: <string>

Header Reference: <string>

The main string types, common operations, and usage patterns around std::basic_string and std::string.

How to use this reference page

Use reference pages to confirm names, categories, nearby facilities, and the constraints that matter before writing or reviewing code.

  • Scan the top of the page first to identify the primary types, functions, or algorithm families involved.
  • Use the nearby-page links when your question is really about a companion header, related algorithm family, or broader subsystem.
  • Validate tricky behavior with a small compileable example before relying on memory for details like invalidation, ordering, allocation, or lifetime rules.

What header pages are for

Header reference pages are meant to answer a practical question quickly: what this header provides, when to reach for it, and which usage rules are easiest to get wrong.

  • Start here when you already know roughly which header you need but want a fast operational summary.
  • Use the example section below as a minimal pattern, then adapt it to your real container, ownership, text, or concurrency workflow.
  • Jump to broader index pages when you need exhaustive coverage rather than a header-focused summary.

Header Reference: <string>

Main types

Main facility groups

What it provides

Common operations

Important caveats

Operational details that matter in practice

Example workflow

#include <string>
#include <string_view>

bool is_config_name(std::string_view text) {
	return text.ends_with(".toml");
}

int main() {
	std::string file = "config.toml";
	file.insert(0, "site-");
	return is_config_name(file) ? 0 : 1;
}

When to pair it with other headers

Nearby pages

Minimal example

#include <string>
#include <iostream>

int main() {
    std::string name = "cpp-handbook";
    name.replace(0, 3, "C++");

    if (name.starts_with("C++")) {
        std::cout << name.substr(0, 7) << '\n';
    }
}

What to verify before relying on this header

  • Which operations invalidate iterators, references, pointers, views, or node handles.
  • Whether ordering, hashing, capacity growth, or allocation behavior affects the surrounding design.
  • Whether a non-owning view or a different container would express the real requirement more clearly.