Интеллектуальные указатели - случаи, где они не могут заменить необработанные указатели
Привет,
У меня есть этот запрос об интеллектуальных указателях.
Я получил известие от одного из своих друзей, что интеллектуальные указатели могут почти всегда заменять необработанные указатели. но когда я спросил его, что является другими случаями, где интеллектуальные указатели не могут заменить необработанные указатели, я не получил ответ от него.
кто-либо мог сказать мне, когда и где они не могут заменить необработанные указатели?
7 ответов
- Передача указателей на устаревшие API.
- Обратные ссылки в древовидной структуре с подсчетом ссылок (или в любой циклической ситуации, если на то пошло). Это спорно, так как вы можете использовать weak-ref.
- Итерация по массиву.
Также есть много случаев, когда вы можете использовать интеллектуальные указатели, но можете не захотеть, например:
- Некоторые небольшие программы предназначены для утечки всего, потому что это просто не стоит дополнительных сложностей, связанных с выяснением того, как очистить за собой.
- Детализированные пакетные алгоритмы, такие как анализаторы, могут выделять из предварительно выделенного пула памяти, а затем просто удалять весь пул по завершении. Наличие умных указателей в таком пуле обычно бессмысленно.
Если по какой-то причине необработанный указатель приводится к intptr_t и обратно, его нельзя заменить интеллектуальным указателем, поскольку операция приведения потеряет любую информацию о подсчете ссылок, содержащуюся в интеллектуальном указателе.
Зависит от используемого интеллектуального указателя. std :: auto_ptr несовместим с контейнерами STL.
API, который будет вызываться из C, будет очевидным примером.
Это вопрос семантики:
- умный указатель: вы владеете (по крайней мере частично) памятью, на которую указывает, и, как таковой, несете ответственность за ее освобождение.
- обычный указатель: вам предоставляется дескриптор для объект ... или нет (NULL)
Например:
class FooContainer
{
public:
typedef std::vector<Foo> foos_t;
foos_t::const_iterator fooById(int id) const; // natural right ?
};
Но вы раскрываете некоторые детали реализации здесь, вы могли бы прекрасно создать свой собственный класс итератора ... но итератор обычно означает увеличиваемый и т. д ... или использовать указатель
class FooContainer
{
public:
const Foo* fooById(int id) const;
};
Возможно, он вернет NULL , что указывает на сбой, или вернет указатель на объект, для которого вам не нужно обрабатывать память.
Конечно, вы также можете использовать здесь weak_ptr (вы получаете метод с истекшим сроком ), однако для этого в первую очередь потребуется использовать shared_ptr и вы можете не использовать их в своей реализации.
взаимодействие с устаревшим кодом. если api нужен необработанный указатель, вам необходимо предоставить необработанный указатель, даже если он в вашем коде вы оберните его в интеллектуальный указатель.
Было бы довольно сложно реализовать интеллектуальные указатели, если в какой-то момент вы не используете простые указатели.
Я полагаю, что также будет сложнее реализовать определенные структуры данных с помощью интеллектуальных указателей. Например, освобождение памяти обычного связанного списка довольно тривиально, но нужно подумать, чтобы выяснить комбинацию умных указателей, владеющих и не владеющих, для получения того же результата.