После того, как вы приняли интеллектуальные указатели boost, можно ли использовать необработанные указатели?

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

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

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

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

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

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

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

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

Требуется некоторая осторожность. Умные указатели не эквивалентны сборке мусора.

Я почти не использую 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();
}

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

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

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

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

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

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

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

Поэтому я предпочитаю использовать необработанные указатели, хотя часто с boost :: intrustive_ptr и внутренним счетчиком ссылок.

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

Всего несколько штук в голове:

• Перемещение по файлам с отображением памяти.
• Вызовы Windows API, в которых необходимо выделить избыточное количество ресурсов (например, LPBITMAPINFOHEADER).
• Любой код, в котором вы возитесь с произвольной памятью (VirtualQuery () и т.п.).
• Практически каждый раз, когда вы используете reinterpret_cast <> для указателя.
• Каждый раз, когда вы используете place-new.

Общей чертой здесь является «любая ситуация, в которой вам нужно рассматривать часть памяти как нечто иное, чем ресурс, выделение которого у вас есть».