Так делают обычно? auto engine = std::make_shared<Engine>(); auto car = std::make_shared<Car>(); car.SetEngine(engine);

А почему не в конструкторе передавать?

Нет Shared ptr не нужен

делают, но это скорее обязательная зависимость, так что инъекция через метод выглядит странно немного)

Сильное утверждение

В 99% случаев*

а если потом надо будет заменить двигатель?

потом замените, но в конструкторе хорошо бы хоть какой-то наверное затребовать

но плодить методы SetEngine это норма? как вообще принято? я знаю как в Java, знаю как в C#, но в плюсах никак не разберу

Это не норма даже в джаве и шарпе

здрасьте

Почему? Инкапсуляция же

Потому что чем иммутабельнее объект, тем лучше

Ну так то оно так

Ну Геттеры как раз его делают менее мутабельным

это вы языком тогда ошиблись

Ты хочешь у машины на лету менять движок?

Для всяких DTO это норм, но в плюсах это просто структуры плоские

А сеттеры — более мутабельнее :)

машина движок лишь пример)

Если владелец один, то зачем shared_ptr, а не unique?

потому что фабрика может ссылаться на этот двигатель

может ссылаться, это ещё не значит, что владеть

Короче, shared_ptr надо использовать только там, где имеет место быть общее владение одним объектом несколькими другими. Иначе надо использовать unique_ptr

так я же пишу, машина ссылается на двигатель, фабрика который сделала двигатель ссылается на двигатель

Вы не понимаете что такое владение

> фабрика который сделала двигатель ссылается на двигатель Зачем

а кто владеет двиагетелем? кто его уничтожает и создаёт?

Так у вас не ссылается, а владеет. Такое ощущение, что на одном двигателе может несколько машин уехать

это субъективно, шаред это прежде всего умный указатель

Как и unique_ptr; почему вы выбрали shared?

Это не субъективно Это best practice в С++, которая сложилась за 10 лет

машина может быть уничтожена, но информация о двигателе у фабрики двигателей должна быть

Двигатель и информация о двигателе — это разные сущности

дайте ссылку бест практисов где 99% шареды зло

от архитектуры зависит

Это звучит потрясающе странно Пусть фабрика владеет, раз двигатели в ней живут

Не зависит

в вашем примере шаред не нужен. он нужен, например, если у вас есть фабрика ресурсов (текстур, звуков и т.д.) и есть куча объектов, которые используют эти ресурсы. вы хотите, что бы ресурс был аллоцирован, пока есть пользователи этих объектов. в этом случае shared_ptr может пригодиться

ну я не отрицаю что тут и юник подойдет, достаточно уик держать в фабрике, и при уничтожении машины двигатель обратно передать в фабрику например

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#f27-use-a-shared_ptrt-to-share-ownership https://github.com/cpp-best-practices/cppbestpractices/blob/master/08-Considering_Performance.md Prefer unique_ptr to shared_ptr

пример был выдуман, путь и не очень удачно

если при уничтожении машины, двигатель не уничтожается, то машина им не владеет, а "арендует". в этом случае достаточно использовать в машине обычный голый указатель.

Because of this it is more efficient than the shared_ptr ещё раз говорю, что я соединяю макро компоненты, тут влияние шаредов на производительность - ничтожна

говорят, если вы не на низком уровне, то голые указатели лучше не трогать

Проблема не только в производительности Код сложнее читать потому что "всё владеет всем" — это ужасно

Ну вот же Prefer a unique_ptr over a shared_ptr if there is never more than one owner at a time. shared_ptr is for shared ownership.

не совсем так. их не стоит выделять и удалять самому. но работать с ними можно

shared_ptr нужен не для того, чтобы пользоваться им, когда лень думать о владении

и словить УБ... когда-нибудь

причём тут UB?

)

но и так тоже можно)

В плюсах нельзя не думать о владении

когда под сырым указателем не будет валидного объекта

ваша правда

Нет, это заблуждение. Не трогать лучше new/delete, это разные вещи

а если объект уже кто-то удалил? тот же умный указатель?

shared ptr создан не для этого

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

для этого есть юник. шаред создан, что бы шарить владение между несколькими объектами

да мне надо шарить объект)

для начала можно посмотреть, точно ли для этого не хватит конкретного одного владельца + не владеющих ссылок/указателей

Вам кажется, что нужно :)

Если кто-то удалил, а тот, кто пользуется указателем остался - код говно, используй shared_ptr. Если struct observer {}; struct A { // конструктор // observer* ptr; }; struct B { observer m_observer; A m_a(&m_observer); } То таких проблем не может возникнуть.

тут сам Страуструп велел ссылкой пользоваться

Очень рад за него. А если у нас отложенная инициализация поля unique_ptr в классе B?

Вы таким образом лишь архитектурную проблему маскируете в этом случае.

И в A есть условный SetObserver(observer* ptr)

ссылка мембер банит тебе дефолт и копи конструктор/операторы=

В т.ч.

Не копи, а мув же