🏗 Что на самом деле происходит, когда 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