{"title":"std::string","description":null,"content":"`std::string` is the modern C++ way to handle text. It lives in the `` header, owns its memory, grows automatically when appended to, and behaves like a normal value type that can be copied, compared, and passed around. After raw `char` arrays with a null terminator, this is a relief. For almost any new code, `std::string` is the appropriate default.\n\n---\n\n# Why std::string\n\nThe previous two chapters covered C-strings, which are arrays of `char` with a `'\\0'` byte at the end. They work, but they put a lot of bookkeeping on the programmer. The size must be tracked, the buffer must never overflow, the null terminator must never be forgotten, and a separate function (`strcmp`) is required for comparison because `==` checks pointer addresses, not text. Each of these is a real bug class that has caused real outages.\n\n`std::string` removes that bookkeeping. The class wraps a buffer, tracks the size, manages the memory, and provides `==` that compares text. The same job done both ways.\n\nC-string version:\n\n\n```cpp\n#include \n#include \n\nint main() {\n char firstName[20] = \"Ada\";\n char lastName[20] = \"Lovelace\";\n\n char fullName[40];\n std::strcpy(fullName, firstName);\n std::strcat(fullName, \" \");\n std::strcat(fullName, lastName);\n\n std::cout << \"Hello, \" << fullName << \"!\" << std::endl;\n return 0;\n}\n```\n\n\nIt works, but the size of `fullName` had to be picked upfront. Too small, and the concatenation walks off the end of the buffer, corrupting memory. Too big, and space is wasted. The compiler gives no warning if the size is wrong.\n\nThe same code with `std::string`:\n\n\n```cpp\n#include \n#include \n\nint main() {\n std::string firstName = \"Ada\";\n std::string lastName = \"Lovelace\";\n\n std::string fullName = firstName + \" \" + lastName;\n\n std::cout << \"Hello, \" << fullName << \"!\" << std::endl;\n return 0;\n}\n```\n\n\nNo size picking. No buffer overflow risk. The `+` operator stitches the pieces together and `fullName` grows to fit. If `lastName` were a hundred characters long, the same code would still work without a single change.\n\nHere is what `std::string` provides.\n\n---\n\n# The `` Header\n\nTo use `std::string`, include the `` header:\n\n\n```cpp\n#include \n```\n\n\n`` often transitively includes something that makes `std::string` work, but that is an implementation accident, not a guarantee. Include `` explicitly when it is used. Code that compiles on one compiler without the explicit include can fail on another.\n\nThe full type name is `std::string`. The `std::` prefix is the namespace the standard library lives in. Most lessons in this course use the explicit prefix instead of `using namespace std;` because it shows clearly where each name comes from.\n\n---\n\n# Constructing Strings\n\nA few common ways to make a `std::string`:\n\n\n```cpp\n#include \n#include \n\nint main() {\n std::string empty; // default: \"\"\n std::string fromLiteral = \"Wireless Mouse\";\n std::string copy = fromLiteral; // copy of another std::string\n std::string repeated(5, '*'); // five '*' characters\n std::string fromSubstring(fromLiteral, 9, 5); // \"Mouse\" (substring)\n\n std::cout << \"empty: [\" << empty << \"]\" << std::endl;\n std::cout << \"fromLiteral: [\" << fromLiteral << \"]\" << std::endl;\n std::cout << \"copy: [\" << copy << \"]\" << std::endl;\n std::cout << \"repeated: [\" << repeated << \"]\" << std::endl;\n std::cout << \"fromSubstring:[\" << fromSubstring << \"]\" << std::endl;\n return 0;\n}\n```\n\n\nWhat each line does:\n\n- `std::string empty;` builds an empty string. It has size `0` and prints as nothing.\n- `std::string fromLiteral = \"Wireless Mouse\";` builds a string from a C-string literal. The literal gets copied into the new `std::string`'s own buffer.\n- `std::string copy = fromLiteral;` makes an independent copy. Modifying `copy` later does not affect `fromLiteral`.\n- `std::string repeated(5, '*');` builds `\"*****\"`: five copies of one character. Useful for separators or padding.\n- `std::string fromSubstring(fromLiteral, 9, 5);` builds a new string from a slice of `fromLiteral`, starting at index `9` and taking `5` characters.\n\nInitialization with `=` and initialization with parentheses both work, but they are not always interchangeable. `std::string s = \"abc\";` and `std::string s(\"abc\");` produce the same result. `std::string s(5, '*');` and `std::string s = (5, '*');` do not, because the second one uses the comma operator and produces a single character. Use parentheses when passing arguments other than a single literal.\n\nConstructing a `std::string` from a C-string literal copies the bytes into a buffer the string owns. For short strings, that buffer may live inside the string object itself (more on this below). For long strings, it lives on the heap.\n\n---\n\n# Concatenation\n\n`std::string` overloads `+` and `+=` for concatenation. Both produce a string that contains the left side followed by the right side.\n\n\n```cpp\n#include \n#include \n\nint main() {\n std::string firstName = \"Grace\";\n std::string lastName = \"Hopper\";\n\n std::string fullName = firstName + \" \" + lastName;\n std::cout << fullName << std::endl;\n\n std::string greeting = \"Hello, \";\n greeting += fullName;\n greeting += \"!\";\n std::cout << greeting << std::endl;\n return 0;\n}\n```\n\n\nA few details:\n\n- The right side of `+` and `+=` can be a `std::string`, a C-string literal, or a single `char`. All three work.\n- `+` produces a new string. It does not modify either operand.\n- `+=` modifies the left side in place and returns a reference to it.\n\nThat second point matters for performance. `+` has to allocate space for the result, copy both operands into it, and return the new string. `+=` can often grow the existing buffer (if capacity is available) and append the new characters, which avoids an allocation.\n\n`a = a + b` allocates a new string, copies both `a` and `b` into it, and assigns. `a += b` appends `b` to `a`'s existing buffer (allocating only if the buffer is too small). For repeated appending in a loop, prefer `+=`.\n\nA common case: building a product title from parts.\n\n\n```cpp\n#include \n#include \n\nint main() {\n std::string brand = \"Acme\";\n std::string model = \"X100\";\n std::string title;\n\n title += brand;\n title += \" \";\n title += model;\n title += \" Wireless Mouse\";\n\n std::cout << title << std::endl;\n return 0;\n}\n```\n\n\nYou can also concatenate a `char` directly:\n\n\n```cpp\n#include \n#include \n\nint main() {\n std::string searchQuery = \"wireless\";\n searchQuery += ' ';\n searchQuery += 'm';\n searchQuery += 'o';\n searchQuery += 'u';\n searchQuery += 's';\n searchQuery += 'e';\n std::cout << searchQuery << std::endl;\n return 0;\n}\n```\n\n\nNot useful for real code, but it shows that `char` is a valid right-hand operand for `+=`.\n\nOne thing that does not work is concatenating two C-string literals with `+`:\n\n\n```cpp\nstd::string s = \"Hello, \" + \"world!\"; // compile error\n```\n\n\n`g++` reports:\n\n\n```shell\nerror: invalid operands of types 'const char [8]' and 'const char [7]' to binary 'operator+'\n```\n\n\nBoth sides are C-string literals (raw `const char` arrays), and the language does not define `+` for two of those. To fix it, one side has to be a `std::string`:\n\n\n```cpp\nstd::string s = std::string(\"Hello, \") + \"world!\"; // works\nstd::string s2 = \"Hello, \" + std::string(\"world!\"); // also works\n```\n\n\nIn typical code, a `std::string` variable is on one side anyway, so this issue comes up mainly when writing one-line constants.\n\n---\n\n# Comparison\n\n`std::string` supports `==`, `!=`, `<`, `<=`, `>`, `>=` directly. `==` and `!=` compare the text. `<`, `<=`, `>`, `>=` compare lexicographically, which is character-by-character using each character's numeric value.\n\n\n```cpp\n#include \n#include \n\nint main() {\n std::string a = \"apple\";\n std::string b = \"apple\";\n std::string c = \"banana\";\n\n std::cout << (a == b) << std::endl; // 1 (true)\n std::cout << (a == c) << std::endl; // 0 (false)\n std::cout << (a != c) << std::endl; // 1 (true)\n std::cout << (a < c) << std::endl; // 1 (apple comes before banana)\n std::cout << (c > a) << std::endl; // 1\n return 0;\n}\n```\n\n\nThis is one of the biggest improvements over C-strings. With C-strings, `==` compares pointer addresses, not text, and almost always gives the wrong answer. With `std::string`, `==` compares the text.\n\nLexicographic comparison works through the strings character by character. The first character where they differ decides the order. If one string is a prefix of the other, the shorter one is \"less.\"\n\n\n```cpp\n#include \n#include \n\nint main() {\n std::cout << (std::string(\"apple\") < std::string(\"apricot\")) << std::endl; // 1\n std::cout << (std::string(\"apple\") < std::string(\"app\")) << std::endl; // 0\n std::cout << (std::string(\"App\") < std::string(\"apple\")) << std::endl; // 1\n return 0;\n}\n```\n\n\nThe third comparison is the surprising one. `'A'` is `65` in ASCII and `'a'` is `97`, so uppercase letters sort before lowercase ones. `\"App\"` is \"less than\" `\"apple\"` because the first character `'A'` (65) is less than `'a'` (97). For case-insensitive comparison, either write a custom comparison or convert both strings to the same case first.\n\nYou can also compare a `std::string` with a C-string literal:\n\n\n```cpp\n#include \n#include \n\nint main() {\n std::string status = \"shipped\";\n if (status == \"shipped\") {\n std::cout << \"Order is on its way.\" << std::endl;\n }\n return 0;\n}\n```\n\n\nThe literal gets implicitly compared as a string. This is the most common form of comparison.\n\n---\n\n# Element Access\n\nRead or write individual characters in a `std::string` using `[]` or `.at()`. They both take a zero-based index and return a reference to that character.\n\n\n```cpp\n#include \n#include \n\nint main() {\n std::string product = \"Laptop\";\n std::cout << product[0] << std::endl; // 'L'\n std::cout << product[5] << std::endl; // 'p'\n\n product[0] = 'l';\n std::cout << product << std::endl; // \"laptop\"\n return 0;\n}\n```\n\n\nThe difference between `[]` and `.at()` is what happens out of bounds. `[]` is undefined behavior: the program may crash, may read arbitrary memory, or may appear to work and corrupt memory elsewhere. `.at()` does a bounds check and throws `std::out_of_range` if the index is invalid.\n\n\n```cpp\n#include \n#include \n#include \n\nint main() {\n std::string product = \"Laptop\";\n\n try {\n char c = product.at(10); // out of range\n std::cout << c << std::endl;\n } catch (const std::out_of_range& e) {\n std::cout << \"Caught: \" << e.what() << std::endl;\n }\n return 0;\n}\n```\n\n\n(The exact message varies between standard library implementations, but the type is always `std::out_of_range`.)\n\nWhich to use? Use `[]` when the index is already known to be in range (for example, inside a loop bounded by `.size()`). Use `.at()` when the index came from user input or an untrusted source and an exception is preferable to memory corruption.\n\nThere are also convenience methods for the first and last character:\n\n\n```cpp\n#include \n#include \n\nint main() {\n std::string product = \"Laptop\";\n std::cout << product.front() << std::endl; // 'L'\n std::cout << product.back() << std::endl; // 'p'\n return 0;\n}\n```\n\n\n`.front()` is equivalent to `s[0]` and `.back()` is equivalent to `s[s.size() - 1]`. Calling either on an empty string is undefined behavior, so check `.empty()` first if the string might be empty.\n\n`[]`, `.at()`, `.front()`, and `.back()` are all O(1). `.at()` is slightly slower than `[]` because of the bounds check, but for most code that difference does not matter.\n\n---\n\n# Size and Empty\n\n`std::string` knows its own size in constant time. There is no need to walk through the string counting characters the way `strlen` does on a C-string.\n\n\n```cpp\n#include \n#include \n\nint main() {\n std::string email = \"ada@example.com\";\n std::cout << \"size: \" << email.size() << std::endl;\n std::cout << \"length: \" << email.length() << std::endl;\n std::cout << \"empty: \" << email.empty() << std::endl;\n\n std::string blank;\n std::cout << \"blank size: \" << blank.size() << std::endl;\n std::cout << \"blank empty: \" << blank.empty() << std::endl;\n return 0;\n}\n```\n\n\nA few points:\n\n- `.size()` and `.length()` are identical. They both return the number of characters (not counting any null terminator). The two names exist for historical reasons. Pick one and use it consistently. Most modern code uses `.size()` because it matches the convention in other containers (`std::vector::size()`, `std::array::size()`).\n- `.empty()` returns `true` if the string has zero characters. It is the same as writing `s.size() == 0`, but reads more clearly and is the conventional way to check.\n- Both methods are O(1). `std::string` stores the size in a member, so reading it does not require walking the buffer.\n\nThere is also `.capacity()`, which returns how many characters the string can hold without reallocating its buffer. It rarely needs explicit attention. `std::string` grows automatically as appending happens, so the capacity adjusts on its own. The one case where it matters is appending in a loop where repeated reallocations should be avoided: calling `.reserve(n)` upfront tells the string to allocate space for `n` characters now. That is a tuning detail to address once profiling shows it matters.\n\n`.size()`, `.length()`, and `.empty()` are O(1) on `std::string`. The equivalent on a C-string is `strlen()`, which is O(n) because it has to scan to the null terminator. That is one of the practical reasons `std::string` is preferred for any code that asks the length more than once.\n\n---\n\n# Reading Input\n\nThere are two common ways to read a `std::string` from standard input: `std::cin >> word` and `std::getline(std::cin, line)`. They behave differently, and picking the wrong one is a frequent source of bugs.\n\n`std::cin >> word` reads one whitespace-separated word at a time. It skips leading whitespace, then reads characters until it hits whitespace again, and stops there. The whitespace is left in the input buffer.\n\n\n```cpp\n#include \n#include \n\nint main() {\n std::string firstName;\n std::cout << \"Enter your first name: \";\n std::cin >> firstName;\n std::cout << \"Hello, \" << firstName << \"!\" << std::endl;\n return 0;\n}\n```\n\n\nIf the user types `Ada Lovelace`, only `Ada` ends up in `firstName`. The space and `Lovelace` are still sitting in the input buffer, waiting for the next read.\n\n**Sample run:**\n\n\n```shell\nEnter your first name: Ada Lovelace\nHello, Ada!\n```\n\n\n`std::getline(std::cin, line)` reads the rest of the current line, including spaces, up to (but not including) the newline. It is the appropriate choice for reading a full name, an address, or a search query.\n\n\n```cpp\n#include \n#include \n\nint main() {\n std::string fullName;\n std::cout << \"Enter your full name: \";\n std::getline(std::cin, fullName);\n std::cout << \"Hello, \" << fullName << \"!\" << std::endl;\n return 0;\n}\n```\n\n\n**Sample run:**\n\n\n```shell\nEnter your full name: Ada Lovelace\nHello, Ada Lovelace!\n```\n\n\nA common bug is mixing the two. If `std::cin >> something` runs first and then `std::getline`, the `getline` reads whatever is left on the line, which is often the newline character alone, giving an empty string.\n\n\n```cpp\n#include \n#include \n\nint main() {\n int productId;\n std::string productName;\n\n std::cout << \"Enter product ID: \";\n std::cin >> productId;\n\n std::cout << \"Enter product name: \";\n std::getline(std::cin, productName); // reads empty line!\n std::cout << \"ID: \" << productId << \", Name: [\" << productName << \"]\" << std::endl;\n return 0;\n}\n```\n\n\n**Sample run:**\n\n\n```shell\nEnter product ID: 42\nEnter product name: ID: 42, Name: []\n```\n\n\nThe `std::cin >> productId` consumes the number but leaves the trailing newline in the buffer. `std::getline` then reads up to that newline, which is right there, so it gets an empty string and `productName` is empty.\n\nThe fix is to clear the leftover newline before calling `std::getline`:\n\n\n```cpp\n#include \n#include \n#include \n\nint main() {\n int productId;\n std::string productName;\n\n std::cout << \"Enter product ID: \";\n std::cin >> productId;\n std::cin.ignore(std::numeric_limits::max(), '\\n');\n\n std::cout << \"Enter product name: \";\n std::getline(std::cin, productName);\n std::cout << \"ID: \" << productId << \", Name: [\" << productName << \"]\" << std::endl;\n return 0;\n}\n```\n\n\n**Sample run:**\n\n\n```shell\nEnter product ID: 42\nEnter product name: Wireless Mouse\nID: 42, Name: [Wireless Mouse]\n```\n\n\nThe `std::cin.ignore(...)` call throws away everything up to and including the next newline, so `getline` starts fresh on the next line of input. This pattern applies any time `>>` is mixed with `getline`.\n\n---\n\n# Interop with C-Strings\n\nSome functions and APIs take a `const char*`. The `.c_str()` method returns a pointer to a null-terminated C-string view of the string's contents.\n\n\n```cpp\n#include \n#include \n#include \n\nint main() {\n std::string email = \"ada@example.com\";\n\n // std::printf takes a C-string for its format and arguments\n std::printf(\"Email: %s\\n\", email.c_str());\n\n return 0;\n}\n```\n\n\nA few rules for `.c_str()`:\n\n- The returned pointer is `const char*`. The characters can be read but not modified.\n- The pointer is valid until the string is modified or destroyed. After an append or after the string goes out of scope, the pointer is no longer safe to use.\n- The string contents are always null-terminated when accessed through `.c_str()`.\n\nSince C++11, there is also `.data()`. For most purposes, `.data()` and `.c_str()` behave the same: both return a pointer to the buffer, and both are null-terminated. The historical difference (pre-C++11, `.data()` was not guaranteed null-terminated) is gone, so use whichever name reads better. Most code still uses `.c_str()` because the name signals \"a C-string view of this\".\n\n`.c_str()` is O(1) since C++11. The implementation maintains the null terminator as part of the buffer, so no copy or allocation happens on the call.\n\nGoing the other way is simpler. A `const char*` (which is what a C-string literal decays to) can be implicitly converted to a `std::string`, so C-strings can be passed anywhere a `std::string` is expected:\n\n\n```cpp\n#include \n#include \n\nvoid greet(const std::string& name) {\n std::cout << \"Hello, \" << name << \"!\" << std::endl;\n}\n\nint main() {\n const char* legacyName = \"Linus\";\n greet(legacyName); // implicit conversion to std::string\n greet(\"Bjarne\"); // same thing, literal is a const char*\n return 0;\n}\n```\n\n\nThe function `greet` takes a `const std::string&`, but a C-string can be passed and the compiler constructs a temporary `std::string` from it for the duration of the call. This makes mixing `std::string` with older C-string-based code mostly painless.\n\n---\n\n# Internal Layout\n\nThe internals of `std::string` are not required knowledge, but a rough picture helps explain why some operations are fast and others are not.\n\nA `std::string` object holds three pieces of information: a pointer to the character buffer, the size (current number of characters), and the capacity (how many characters the buffer can hold). A call to `.size()` returns the size member directly. An append writes into the buffer up to the capacity, and only reallocates when no room is left.\n\n\n```mermaid\nflowchart LR\n SO[std::string object
on the stack]:::cyan\n PTR[pointer
to buffer]:::orange\n SZ[size
5]:::teal\n CAP[capacity
15]:::teal\n BUF[heap buffer
Mouse...........]:::green\n\n SO --> PTR\n SO --> SZ\n SO --> CAP\n PTR --> BUF\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe diagram shows the conceptual layout for a longer string. The `std::string` object itself sits in whatever scope it was declared in (often the stack), and it holds a pointer to a separate buffer that lives on the heap. The size says how many characters are in use; the capacity says how many slots the buffer has total.\n\nOne important detail: **small string optimization (SSO)**. Most standard library implementations skip the heap allocation entirely for short strings (typically up to 15 or 22 characters, depending on the implementation) by storing the characters inside the `std::string` object itself, in space that would otherwise be unused. This is invisible from the outside, the data API is the same, but it means creating short strings is essentially free. A `std::string s = \"ok\";` does not trigger a heap allocation.\n\nThe exact cutoff and the SSO implementation are not required reading. The takeaway: short `std::string` values are not heavy.\n\n---\n\n# Why std::string Beats char[]\n\nA side-by-side comparison.\n\n\n| Aspect | `char[]` (C-string) | `std::string` |\n|--------|---------------------|---------------|\n| Knows its own size | No, you call `strlen`, which is O(n) | Yes, `.size()` is O(1) |\n| Grows when needed | No, fixed size at declaration | Yes, automatically |\n| Manages its own memory | No, you allocate and free | Yes, RAII handles it |\n| Safe from buffer overflow | No, easy to overflow | Yes, grows or throws |\n| `==` compares text | No, compares pointer addresses | Yes |\n| `+` for concatenation | No, use `strcat` (and pre-allocate) | Yes |\n| Copyable with `=` | No, that just copies the pointer | Yes, full deep copy |\n| Comparable with `<` for sorting | No, use `strcmp` | Yes, lexicographic |\n| Works directly with standard containers | Awkward | Natural |\n| Interop with C APIs | Native | One call to `.c_str()` |\n\n\nEvery row in the C-string column is a real bug source. Forgetting to allocate enough space, forgetting the null terminator, using `==` thinking it compares text, leaking memory because no one called `delete[]`. `std::string` removes those failure modes.\n\nThat is what the advice \"use `std::string` for all text\" means. For new code, there is almost no reason to use `char[]`. The exceptions are narrow: interfacing with a C API that requires a writable `char*`, or an embedded environment where heap allocation is not available. For everything else, `std::string` is the default.\n\n---\n\n# Other String Types\n\n`std::string` holds `char` values, which are typically one byte each and work well for ASCII text. For other character types, the standard library provides parallel types:\n\n- `std::wstring` holds `wchar_t`, used on Windows for \"wide\" characters.\n- `std::u8string` (since C++20) holds `char8_t`, for UTF-8 encoded text.\n- `std::u16string` holds `char16_t`, for UTF-16.\n- `std::u32string` holds `char32_t`, for UTF-32.\n\nThey all share the same API as `std::string`. The trade-offs around when to use each one (and how to handle Unicode properly in general) are beyond this lesson. For the rest of this course, \"string\" means `std::string`, which is the default for almost any code.","pageType":"cpp"}

std::string

Get Premium