Использование объектов или указателей на объекты в качестве членов класса и выделение памяти

Скажем, у меня есть объект, содержащий три вектора stl. Правильно ли я думаю, что если они являются обычными членами класса, память о них будет «вместе» для всего объекта? например моя память будет выглядеть как 10 блоков вектора A, 5 блоков вектора B, а затем 15 блоков вектора C.

Каждый vector занимает фиксированный размер в содержащем объекте, независимо от количества элементов, хранящихся в данный момент в vector. Вполне вероятно, что value_type из vector (например, vector<int> имеет value_type int) не повлияет на размер самого содержащегося объекта vector: только объем выделенного в куче хранилища, необходимого vector для поддержания емкости хранилища (поэтому они вроде бы будет 8 или 16 или 32 байта каждый, но все равно, но не 10 "блоков" (что бы это ни было), 5 блоков и 15).

Будет ли тогда, когда я вставлю больше объектов в вектор A, чтобы пространство закончилось, вся структура, включая вектор B и C, должна быть перемещена?

Вставка элементов в A может привести только к перемещению существующих элементов в A (при превышении емкости). B и C никогда не могут быть затронуты.

Это аргумент в пользу указателей? Или векторы внутри являются только указателем на выделенную память?

ДА, это аргумент... настолько хороший, что ДА, vectors уже делают использование указателей на непрерывную память, где фактически хранятся value_type элементов.

Тот же вопрос касается списков и т.д.

ДА, list также хранят свои value_type элементы в куче, а размер объекта, внедренного или полученного из list, не зависит от операций над list.

Существуют ли какие-либо эмпирические правила относительно стоимости перенаправления и стоимости копирования небольших объектов? Может быть, что-то вроде перенаправления 5 указателей = 1 целочисленная копия?enter code here

C++ работает на слишком многих платформах, чтобы для этого существовали хорошие эмпирические правила. Даже, скажем, на процессорах x86 различия в наборе инструкций, # ядрах, размерах кэша, поставщике/модели/поколении процессора и т. д. могут быть огромными. Косвенность обходится наиболее дорого, если приводит к ошибкам страниц памяти, а это очень зависит от общей картины выполнения программы на машине. Если вам небезразлично, протестируйте реальные компьютеры, на которых запущена программа, пока не получите статистически значимые и стабильные результаты.

Классы коллекций реализуются внутри с помощью указателей — вам не нужно беспокоиться о том, что им не хватит места. Что касается накладных расходов на копирование, не беспокойтесь об этом, если только вы не доказали профилированием своего кода, что это проблема.

Поскольку std::vector имеют динамический размер, они не могут хранить свои элементы как члены или как массив элементов. Помните, что размер объекта известен во время компиляции.

Но даже в этом случае есть еще кое-что, что можно сказать о неиспользовании членов-указателей. Рассмотрим этот тип:

struct fat {
    array<double, 30> data;
    array<long, 30> more_data;
    array<char, 30> too_much_data;
};

где array может быть std::array, std::tr1::array или boost::array; здесь он просто используется в качестве замены для большого шрифта. Вы правы, что fat объекты будут, ну, большими. Преобразование членов в указатели (или динамические массивы или любой моральный эквивалент) все еще преждевременно: сначала используйте объекты как есть, а затем, если они слишком велики или проблематичны, вы можете вместо этого динамически выделить их членов:

fat* so_much_stuff = new fat[30]();
// Better:
std::vector<fat> get_rid_of_it_already(30);

Семантика значений просто упрощает задачу; только до тех пор, пока не будет слишком много копирования или размера или чего-то еще (сначала измерьте) но не раньше, вы должны использовать (динамические) контейнеры и интеллектуальные указатели (которые сами следуют семантике значений).

ИЗМЕНИТЬ

std::vector в целом неплохой (как участник или нет), см. обсуждение с Тони в комментариях.