✂️ C++17: Перестаньте копировать строки! (std::string_view)

Мы привыкли передавать строки в функции по константной ссылке: const std::string&. Нам кажется, что это эффективно, ведь мы не копируем объект, верно?

Не всегда. 🛑

Если вы передаете в такую функцию обычный текст в кавычках (строковый литерал) или часть другой строки, C++ втайне от вас создаст временный объект std::string, выделит память в куче (heap allocation), скопирует туда данные и только потом передаст ссылку.

Решение? std::string_view.

👀 Что это такое?
std::string_view - это супер-легкий объект, который ничего не хранит сам. Он просто «смотрит» на существующую строку. Внутри него только указатель на начало текста и длина.

Никаких аллокаций. Никаких копий. Ноль оверхеда.

🆚 Сравним:

// 🐢 ПЛОХО (до C++17)
void Log(const std::string& msg) { /* ... */ }

// При вызове создается временный std::string!
Log("Critical Error"); 

// 🚀 ХОРОШО (C++17)
void Log(std::string_view msg) { /* ... */ }

// Никаких аллокаций. Просто передаем указатель и длину.
Log("Critical Error"); 

🔥 Суперсила: Substrings без боли
Самое вкусное начинается, когда нужно взять подстроку.

⚫️std::string::substr() - создает новую строку (копирование + аллокация).
⚫️std::string_view::substr() - просто сдвигает указатель и меняет размер (математическая операция за наносекунды).

⚠️ Осторожно! (Подводный камень)
Так как string_view не владеет данными, а только смотрит на них, вы должны быть уверены, что исходная строка живет дольше, чем string_view.

⚫️ ✅ Использовать как аргумент функции.
⚫️ ❌ Возвращать из функции, если исходная строка была локальной переменной.

💡 Итог:
Если вам нужно только «почитать» строку (в аргументах функции), почти всегда используйте std::string_view вместо const std::string&.

#cpp #cpp17 #optimization #stringview #coding #tips

➡️ @cpp_geek

🏗 Что на самом деле происходит, когда std::vector «лопается»?

Мы все любим push_back. Это удобно: кидаешь данные в вектор, а он сам разбирается с памятью. Но что происходит, когда вы добавляете элемент, а capacity (вместимость) вектора закончилась?

Происходит Реаллокация (Reallocation). И это гораздо дороже, чем кажется.

⚙️ Алгоритм катастрофы:

1. Поиск новой земли: Вектор понимает, что места нет. Он обращается к оперативной памяти и просит выделить новый блок памяти. Обычно он в 1.5 или 2 раза больше текущего.

2. Великое переселение: Все элементы из старого блока памяти копируются (или перемещаются, если есть noexcept move-конструктор) в новый блок.
⚫️Если у вас там 1,000,000 тяжелых объектов - удачи процессору. 😅


3. Уничтожение: Для всех объектов в старом блоке вызываются деструкторы.

4. Снос: Старый блок памяти возвращается системе.

🚨 Почему это проблема?

1. Удар по производительности:
Обычно push_back работает за O(1) (мгновенно). Но в момент реаллокации сложность подскакивает до O(N). Это создает непредсказуемые лаги (latency spikes). В системах реального времени (gamedev, high-load) это недопустимо.

2. Инвалидация итераторов и ссылок (ОПАСНО):
Это источник багов №1.

std::vector<int> vec = {1, 2, 3};
int& ref = vec[0]; // Ссылка на первый элемент

// ... добавляем много элементов ...
for(int i=0; i < 100; ++i) vec.push_back(i);

// 💥 Вектор переехал в новую память. 
// Старая память удалена. ref теперь указывает в мусор.
std::cout << ref; // Undefined Behavior (Crash)

🛡 Как лечить?

Если вы хотя бы примерно знаете, сколько элементов будет в векторе, всегда используйте reserve().

std::vector<User> users;
users.reserve(1000); // Сразу выделяем память

// Теперь первые 1000 push_back будут дешевыми
// и не вызовут реаллокации.

💡 Итог: std::vector это отличный инструмент, но за его «магию» расширения платит процессор. Помогайте ему через reserve().

#cpp #stdvector #performance #memory #coding #tips

➡️ @cpp_geek