Здравствуйте, R1K0, Вы писали:

RK>Вопросы в следующем:
RK>1. Если я создам объект класса APtr, то он создается в куче и, по идее, его атрибут — а — тоже должен быть в куче — правильно?
— У APtr нет аттрибута a, у него есть какойнить приватный A * m_ptr, который указывает на объект A, размещенный на куче, у которого как раз и есть аттрибут a
объект класса APtr скорее всего будет создан на стеке, ибо нормальное его использование:
APtr smartPointerToClassA = make_shared<A>();
а не
APtr * smartPointerToClassA = new APtr( make_shared<a>() );

RK>2. Если я создам объект класса BPtr, то он также создается в куче, но у него есть атрибут — b — который отдельно создается в куче — и они все в куче — правильно ?
с учетом предыдущего:
объект BPtr создается на стеке, в нем есть указатель, адресующий объект B, созданный в отдельном куске на куче, и содержащий int B::b и B::APtr. B::APtr в свою очередь имеет указатель, адресущий объект A, созданный в каком-то другом куске кучи (и содержаший A::a)
RK>3. Ну и создаю я объект класса CPtr — он так же в куче, но он содержит объект класса А, который вроде как стековый — или он все равно в куче как часть объекта CPtr?
На стеке будет создан CPtr, у которого есть указатель, который адресует обект C, созданный на куче и содержаший в себе c и A (который в свою очередь содержит в себе A::a)
RK>4. Ну и исходя из вопросов 2 и 3 — какая практика лучше — создавать объекты клаcс BPtr или CPtr, или, скорее, в каком случае какая практика лучше?
С точки зрения архитектуры — надо смотреть конкретную архитектуру.
С точки зрения производительности:
— если у тебя их не мульены — без разницы (ну, вариант 3 может быть более дружественен к кешу, но если не мульены — то и пофиг)
— если у тебя их мульены — все варианты — какашка, нужно переделывать под контейнеры и, в зависимости от процесса обработки данных может быть выгоден как вариант 2, так и 3.

Здравствуйте, R1K0, Вы писали:

RK>Вопросы в следующем:
RK>1. Если я создам объект класса APtr, то он создается в куче и, по идее, его атрибут — а — тоже должен быть в куче — правильно?
— У APtr нет аттрибута a, у него есть какойнить приватный A * m_ptr, который указывает на объект A, размещенный на куче, у которого как раз и есть аттрибут a
объект класса APtr скорее всего будет создан на стеке, ибо нормальное его использование:
APtr smartPointerToClassA = make_shared<A>();
а не
APtr * smartPointerToClassA = new APtr( make_shared<a>() );

RK>2. Если я создам объект класса BPtr, то он также создается в куче, но у него есть атрибут — b — который отдельно создается в куче — и они все в куче — правильно ?
с учетом предыдущего:
объект BPtr создается на стеке, в нем есть указатель, адресующий объект B, созданный в отдельном куске на куче, и содержащий int B::b и B::APtr. B::APtr в свою очередь имеет указатель, адресущий объект A, созданный в каком-то другом куске кучи (и содержаший A::a)
RK>3. Ну и создаю я объект класса CPtr — он так же в куче, но он содержит объект класса А, который вроде как стековый — или он все равно в куче как часть объекта CPtr?
На стеке будет создан CPtr, у которого есть указатель, который адресует обект C, созданный на куче и содержаший в себе c и A (который в свою очередь содержит в себе A::a)
RK>4. Ну и исходя из вопросов 2 и 3 — какая практика лучше — создавать объекты клаcс BPtr или CPtr, или, скорее, в каком случае какая практика лучше?
С точки зрения архитектуры — надо смотреть конкретную архитектуру.
С точки зрения производительности:
— если у тебя их не мульены — без разницы (ну, вариант 3 может быть более дружественен к кешу, но если не мульены — то и пофиг)
— если у тебя их мульены — все варианты — какашка, нужно переделывать под контейнеры и, в зависимости от процесса обработки данных может быть выгоден как вариант 2, так и 3.

ps/
наврал про мульены и без разницы:
— если у тебя 1 объект к которому очень много обращений, то вариант 3 опять будет быстрей, так-как меньше разыменований.