сомнения меня гложут, как правильно делать?

раньше, если я возвращал какую-то переменную класса геттером, я делал так:

теперь, если у меня в классе переменная идёт, как shared_ptr<T>, то я и должен возвращать ровно shared_ptr<T>, чтобы создалась ещё одна копия, и счётчик таким образом увеличился на 1.

если же я сделаю так:

то это выстрел в ногу, так как счётчик не изменится.

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

Как сложить эти две вещи вместе, возвращать ссылку на объект(это быстро) и авто-контролировать счётчик (это безопасно)? Как вообще правильно работать в данном случае с shared_ptr<T> снаружи классов?

rdb_devCEMb, ты просто забыл включить мозг. ;)я не могу включить то, чего нет, поэтому и пришёл с вопросом.
PPAзачем он у тебя лежит в cpp?а как по коду ты понял, где он лежит?
rdb_devЗдесь подразумевается возврат экземпляра класса-указателя на член типа "T" экземпляра класса "A", а не то, что "shared_ptr<T>" объявлен как член класса.ненене, именно объявлен как shared_ptr<T>, но если это пагубная практика, то расскажите, как правильно. Имхо, неправильно отдавать кому-то shared_ptr<T> если сам объект shared_ptr<T> не является. Грубо говоря, управление памятью должно быть единообразно. Иначе, как вариант: если после геттера объект класса А будет уничтожен, код, получивший shared_ptr<T> не узнает об этом и помешать этому не сможет.

Заново.

Get() создаёт копию объекта shared_ptr<T>, который инициализируется указателем на t_, т.е. с копирование адреса t_ у нас тут проблем нет, но вот с вызовом конструктора shared_ptr<T> - как бы накладные расходы, да? Учение говорит, что возвращать надо ссылки(или указатели, когда нельзя ссылки), иначе будет неявно зваться конструктор.
Но (тот самый вопрос), если мы сделаем так:

то получим ссылку на t_, копирование указателя пройдёт быстро, никаких лишних вызовов и кода (как велит учение), но, опять же, если объект класса А будет уничтожен после геттера, геттер узнает об этом(хоть с трудом, но можно), но помешать этому не сможет.

Вопрос в том: как теперь, в связи с shared_ptr надо отдавать переменные класса. Ну или в обратную сторону: как описывать входящие параметры типа shared_ptr<T> в функциях. Если как ссылки - быстро и ненадёжно, если как объекты, то надёжно и небыстро.

YesSqlпередача по значению - есть передача по значению. И в случае с shared_ptr она может быть достаточно тяжёлой.Эээ тяжёлой, но не достаточно тяжёлой. Это просто вызов конструктора shared_ptr<T> и передача ему указателя на объект. Т.е. тяжело, но не сильно. Но передача по ссылке - всё равно легче.
Dimitry SibiryakovВо-первых, современные компиляторы делают copy elimination, что сильно облегчает процесс.А, блин, точно, там оптимизация по возвращаемому значению же... я забыл про это :(
Ну, т.е. мой вариант

- абсолютно верный? :)
Dimitry SibiryakovВо-вторых, современная парадигма С++ игнорирует вопросы быстродействия в пользу легко
читаемого кода.но при этом авторы сделали очень много, чтобы увеличить это самое быстродействие. Ладно, не будем вдаваться в детали, а то сщас начнётся...

OoCcВсе зависит от задачи. Это не "просто вызов конструктора" это атомик или мютекс в зависимости от имплементации.Ну ок. Так как тогда правильно возвращать значения и передавать параметры в функции? Или зависит от типа?

OoCcПрелесть С++ в том что все зависит от задачи и ее дизайна.так мне-то в вышеприведённом коде, без atomic и mustex, как лучше делать?
rdb_devВозвращай из геттера как "shared_ptr<T>&" - по ссылке и не парься!Нет, так неправильно. Пример:

rdb_dev
интересный момент. Я имел ввиду:

И тогда delete a; уничтожит и t_ тоже (по идее должно, не проверял)
Или, иными словами:Anatoly MoskovskyА если вызывающему коду надо продлить время жизни объекта по этой ссылке, то там надо положить эту ссылку в копию смартуказателя.Т.е. получается, что если мы возвращаем ссылку на shared_ptr, мы оставляем на совести вызывающего следить за тем, жив a в момент вызова Get() или нет.
Ну ок, мне этот вариант больше нравится, спасибо всем :)
Пойду переписывать код...

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

Ынтырпрайзыч(тм)из-за таких вот страдальцев по производительности в ПО обнаруживаются бесконечные дыры. С/С++-жулики не там оптимизируют, они только писчу кибертеррористам дают. Страдайте дальше от лишних 3 инструкций..это проблема, которую можно решить со стороны программиста. Ты же предлагаешь проблему, которую со стороны программиста решить нельзя. Есть люди, которым 3 инструкции (даже 1 инструкция) - это очень критично, при этом они умеют хорошо программировать, и дыр в коде у них нет.

Anatoly MoskovskyЭто не отменяет того что в многопоточном коде ссылки на shared_ptr передавать опасно.Кстати, давайте раскроем эту тему подробнее?