#опытным
Про std::vector сказано многое, но он не перестает удивлять.
Вектор владеет регионом динамической памяти и ему надо трекать, где заканчиваются текущие элементы и где в принципе заканчивается регион.
Наивное представление, которое напишет примерно любой джун:
template<typename T>
class Vector {
...
T * begin;
size_t size;
size_t capacity;
};
Понятно, что в реальности был бы еще аллокатор, тип указателя был бы зависимым типом аллокатора и скорее всего был бы
char *, но смысл один: есть указатель на начало и 2 размера: текущее количество элементов и максимально возможное без переаллокаций.Второй вариант - 3 указателя. Начало, конец текущих данных и конец всего стораджа.
template<typename T>
class Vector {
...
T * begin;
T * end;
T * end_of_storage;
};
И именно последний вариант реализован например в GCC.
У каждого варианта свои плюсы и минусы:
- с помощью 3-х указателей тяжело считать size(), но легко итерироваться и вычислять end().
- указатель и 2 размера легко считают size(), но у них тяжеловато с end().
И в связи с тем, что в С++26 завезли харденинг(рантайм проверки на соблюдение контрактов стандартной библиотеки(например выход за границы массива)) ситуация приобретает интересный поворот.
Харденинг неявно увеличивает количество вызовов метода size(). Поэтому становится выгоднее использовать "наивную" реализацию через указатель и 2 числа.
Ребята из гугла проверили это на своем софте(у них харденинг проверки уже давно реализованы) и получили буст вплоть до 0.6% перфа на количество обработанных запросов в секунду! Не самого вектора, а самих сервисов.
Вот статейка, кому интересно. Крутая статья, кстати. Там в деталях расписано, как внутри std:vector функционирует и еще много всякой полезнятины.
Measure your performance. Stay cool.
#STL #optimization #cpp26