Как только Вы приняли интеллектуальные указатели повышения, есть ли какой-либо случай, где Вы используете необработанные указатели?

Я не использую shared_ptr почти вообще, потому что я избегаю совместно использованного владения в целом. Поэтому я использую что-то как boost::scoped_ptr "владеть" объектом, но всеми другими ссылками на него будет необработанными указателями. Пример:

boost::scoped_ptr<SomeType> my_object(new SomeType);
some_function(my_object.get());

Но some_function будет иметь дело с необработанным указателем:

void some_function(SomeType* some_obj)
{
  assert (some_obj);
  some_obj->whatever();
}

В эти дни я в значительной степени отказался от всего использования необработанных указателей. Я даже начал просматривать нашу кодовую базу для мест, где необработанные указатели использовались и переключили их на вариант интеллектуального указателя. Удивительно, сколько кода я смог удалить путем совершения этого простого поступка. Существует так много кода, потраченного впустую на пожизненное управление необработанными указателями C++.

Единственные места, где я не использую указатели, для нескольких interop сценариев с другими кодовыми базами, которыми я не управляю.

Я нахожу главную разницу между 'современным' C++ и старым*, материал является тщательным использованием инвариантов класса и инкапсуляцией. Хорошо организованный код имеет тенденцию естественно иметь меньше суетящихся указателей. Я почти как нервное плавание в shared_ptrs, как я был бы в новостях и удаляю.

Я с нетерпением жду unique_ptr в C++ 0x. Я думаю, что это уберет несколько (умных) указателей, которые действительно все еще перемещаются дикая местность.

*все еще, к сожалению, очень распространенный

Конечно, любое время, Вы имеете дело с библиотекой прежней версии или API, необходимо будет передать необработанный указатель, хотя Вы, вероятно, просто извлечете его из своего интеллектуального указателя временно.

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

Я все еще использую необработанные указатели на устройствах, которые имеют IO с отображенной памятью, такой как встроенные системы, где наличие интеллектуального указателя действительно не имеет смысла, потому что Вы никогда не будете нуждаться или мочь delete это.

Если у Вас есть круговые структуры данных, например, точки к точкам B и B назад к A, Вы не можете использовать наивно интеллектуальные указатели использования и для A и для B, с тех пор объекты будут только освобождены дополнительная работа. Для освобождения памяти необходимо вручную очистить интеллектуальные указатели, который является почти настолько же плохо, как удаление интеллектуальных указателей избавляется от.

Вы могли бы вещь это не происходить очень часто, но предполагать, что у Вас есть Родительский объект, который имеет интеллектуальные указатели к набору Дочерних объектов. Где-нибудь по пути кто-то должен искать Родителя для Ребенка, таким образом, они добавляют участника интеллектуального указателя к Ребенку, который указывает назад на родителя. Тихо, память больше не освобождается.

Некоторый уход требуется. Интеллектуальные указатели не эквивалентны сборке "мусора".

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

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

О, и существует еще одно место для использования необработанных указателей:

boost::shared_ptr<int> ptr(new int);

Не то, чтобы я сделал бы это, но Вам нужны необработанные указатели для реализации, скажем, связанного списка или графика. Но было бы намного более умно использовать std::list<> или boost::graph<>.

Я пишу C++, который должен сосуществовать с Objective C (использующий Objective C ++ для образования моста). Поскольку объекты C++ объявили как часть Objective C ++, классам не вызвали конструкторов или деструкторы, Вы не можете действительно держать их там в интеллектуальных указателях.

Таким образом, я склонен использовать необработанные указатели, хотя часто с повышением:: intrustive_ptr и внутреннее касательно количества.