Никогда не оправдано. Только вернули raw - полностью потеряли контроль над объектом.

Это вообще как?

Так-то оно так, но для объявления. А если указатель подается в ф-цию/метод, то в подавляющем большинстве случаев никакой умности не требуется. Сравним

C++ (Qt)
void DoSomething( const SomeData * data );
void DoSomething( shared_ptr<SomeData> data );
 

Теперь (2-я строка) ф-ция не сможет удалить данные! И гарантируется что data будет жить даже если вызывающий удален! (актуально при multi-threading). Не очень-то веские причины/резоны. Выходит из заявления shared_ptr ничего по существу не следует, и на него можно не обращать внимания. Зачем тогда заявлять?

Под контролем здесь скорее всего подразумевается управление временем жизни экземпляра объекта. То есть простой механизм сбора мусора?

Ассоциативные связи агрегации (shared/composite) обеспечивают управление временем жизни экземпляра, а вот другие виды ассоциативных связей совершенно не обязаны это делать. Как задать ассоциативную связь отличную от агрегации для unique_ptr, кроме как raw? Обычная ссылка не подойдет, так как во-первых ссылка и указатель сущности разной природы, а во-вторых ссылка не может быть изменена в дальнейшем. Для shared в критических местах тоже лишний раз счетчик трогать нежелательно. Если есть алгоритмическая гарантия того, что экземпляр не удалится во время выполнения (например, заранее заведен guard), то вполне резонно использовать и raw указатель.

Другое дело не рекомендовать использовать сочетания shared/raw, а рекомендовать shared/weak, где это возможно. A shared/raw оставить для продвинутого использования, с учетом того что имеется понимание опасности того, что это за собой влечет.

Для того чтобы совсем отказаться от raw указателей не хватает еще достаточного количества сущностей в стандарте.


Это может быть реализовано как угодно). Можно и свой огород налепить, например, логировать операции с указателем, считать какую-нибудь статистику и т.п., был бы прикладной смысл. Кстати, под shaed не обязательно только shared_ptr понимать. 

Пример

C++ (Qt)
void DoSomething( SomeData * data )
{
  ...
  delete data;
}
 

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

C++ (Qt)
void DoSomething( SomeData *& data )
{
  ...
  delete data;
  data = new ...
 // data = 0; 
}
 

Хорошо, допустим решено, но сколько данных реально шарится? Да %20 отсилы, как бы не меньше
 
В подавляющем большинстве случаев - прекрасно известно. Напр

C++ (Qt)
// вызывающий
DoSomething(theSharedData.get());
 

Не вижу здесь ничего плохого. Написал в ф-ции delete - ну сам "злобный Буратино", в конце-концов мог и в самой ф-ции сделать get и delete. Время жизни - для ф-ции forever. Так от каких мифических угроз защищаемся? А вот утяжеление кода и, особенно, затруднение отладки - минусы очень ощутимые.

Да, shared_ptr гораздо чаще лепится для "сборки мусора" (другого-то ничего нет), а не потому что действительно шарится

Неизвестно.

В С++ имея хоть какой-нибудь доступ к объекту можно его убить. Элементарно:

C++ (Qt)
void DoSomething( SomeClass & some_object )
{
    delete &some_object;
}
 

Никто и не пикнет. А кто вздумает const'ом защищаться, того const_cast'ом обезоружить . Но за такое надо по голове очень сильно бить. И это другая история.


Защищаемся от разыменования nullptr и обращения к убитым объектам. Управляем временем жизни объекта. И в сигнатуре функции, в типах входящих и возвращаемых параметрах, яснее сообщается, что можно делать с объектом, а что нельзя.

И не надо использовать методы умных указателей, которые возвращают raw-указатели. Лучше вообще считать, что их нет( get() и им подобные). Нужны они в особых случаях и для сопряжения с legacy-кодом.