Когда использовать shared_ptr и когда использовать необработанные указатели?

class B;

class A
{
public:
    A ()
        : m_b(new B())
    {
    }

    shared_ptr<B> GimmeB ()
    {
        return m_b;
    }

private:
    shared_ptr<B> m_b;
};

Пусть говорят, что B - это класс, который семантически не должен существовать вне времени жизни A, т.е. абсолютно не имеет смысла, чтобы B существовал сам по себе. Если GimmeB возвращает a shared_ptr<B> или B*?

В целом, хорошая практика - полностью избегать использования необработанных указателей в коде на С++ вместо интеллектуальных указателей?

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

ОТВЕТЫ

Ответ 1

Ваш анализ вполне правильный, я думаю. В этой ситуации я также вернул бы голый B* или даже [const] B&, если объект никогда не будет равен нулю.

Имея некоторое время для изучения интеллектуальных указателей, я пришел к некоторым рекомендациям, которые рассказывают мне, что делать во многих случаях:

  • Если вы возвращаете объект, срок службы которого должен управляться вызывающим абонентом, верните std::unique_ptr. Вызывающий может назначить его std::shared_ptr, если он хочет.
  • Возвращение std::shared_ptr на самом деле довольно редко, и, когда это имеет смысл, это обычно очевидно: вы указываете вызывающему, что он продлит время жизни объекта, указанного за объектом, за время жизни объекта, который первоначально поддерживал ресурс. Возвращение общих указателей с фабрик не является исключением: вы должны это сделать, например. когда вы используете std::enable_shared_from_this.
  • Вам очень редко требуется std::weak_ptr, за исключением случаев, когда вы хотите понять метод lock. У этого есть некоторые виды использования, но они редки. В вашем примере, если время жизни объекта A не было детерминированным с точки зрения вызывающего, это было бы чем-то, что нужно учитывать.
  • Если вы вернете ссылку на существующий объект, время жизни которого вызывающий не может контролировать, верните пустой указатель или ссылку. Поступая таким образом, вы говорите вызывающему, что объект существует и что ей не нужно заботиться о его жизни. Вы должны вернуть ссылку, если вы не используете значение nullptr.

Ответ 2

Вопрос "когда следует использовать shared_ptr и когда следует использовать необработанные указатели?" имеет очень простой ответ:

  • Используйте необработанные указатели, если вы не хотите, чтобы какое-либо право собственности было привязано к указателю. Эта работа также часто может выполняться со ссылками. Необработанные указатели также могут использоваться в некоторых низкоуровневых кодах (например, для реализации интеллектуальных указателей или реализации контейнеров).
  • Используйте unique_ptr или scope_ptr, если вам нужна уникальная собственность на объект. Это самый полезный вариант, и его следует использовать в большинстве случаев. Уникальное право собственности также можно выразить простым созданием объекта напрямую, вместо использования указателя (это даже лучше, чем использование unique_ptr, если это можно сделать).
  • Используйте shared_ptr или intrusive_ptr, если вам требуется совместное владение указателем. Это может быть запутанным и неэффективным, и часто это не очень хороший вариант. Совместное владение может быть полезно в некоторых сложных проектах, но его следует избегать в целом, потому что это приводит к тому, что код трудно понять.

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

Ответ 3

Вот хорошее эмпирическое правило:

  • Когда нет передачи или совместного владения, ссылки или простые указатели достаточно хороши. (Простые указатели более гибкие, чем ссылки.)
  • Когда есть передача права собственности, но нет совместного владения, тогда std::unique_ptr<> является хорошим выбором. Часто бывает с заводскими функциями.
  • Когда есть совместное владение, тогда это хороший вариант использования для std::shared_ptr<> или boost::intrusive_ptr<>.

Лучше всего избегать совместного владения, отчасти потому, что они являются самыми дорогими с точки зрения копирования, а std::shared_ptr<> занимает вдвое больше места хранения простого указателя, но, что наиболее важно, потому что они способствуют плохим проектам, где есть нет явных владельцев, что, в свою очередь, приводит к тому, что объекты не могут разрушаться, потому что они имеют общие указатели друг на друга.

Лучший дизайн - это то, где установлена четкая собственность и иерархическая структура, поэтому в идеале умные указатели вообще не требуются. Например, если существует фабрика, которая создает уникальные объекты или возвращает существующие, имеет смысл для фабрики владеть создаваемыми объектами и просто хранить их по значению в ассоциативном контейнере (например, std::unordered_map), чтобы он может возвращать простые указатели или ссылки на своих пользователей. Эта фабрика должна иметь время жизни, которое начинается до ее первого пользователя и заканчивается после его последнего пользователя (иерархическое свойство), чтобы пользователи не могли иметь указатель на уже уничтоженный объект.

Ответ 4

Если вы не хотите, чтобы вызывающий GimmeB() мог продлить время жизни указателя, сохранив копию ptr после того, как экземпляр A умирает, вы определенно не должны возвращать shared_ptr.

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

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

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

Ответ 5

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

В вашем конкретном случае: почему бы не вернуть ссылку?

Указатель предполагает, что данные могут быть нулевыми, однако в вашем A всегда будет B, поэтому он никогда не будет равен нулю. Ссылка ссылается на это поведение.

Как я уже сказал, я видел людей, которые выступают за использование shared_ptr даже в не-общих средах и предоставляют дескрипторы weak_ptr, с идеей "обеспечения безопасности" приложения и исключения устаревших указателей. К сожалению, поскольку вы можете восстановить shared_ptr из weak_ptr (и это единственный способ фактически манипулировать данными), это по-прежнему совместное владение, даже если оно не должно быть.

Примечание: есть тонкая ошибка с shared_ptr, копия A по умолчанию будет использовать те же B, что и оригинал, если вы явно не пишете конструктор копирования и оператор присваивания копии. И, конечно, вы бы не использовали необработанный указатель в A для хранения B, не могли бы вы:)?

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

Вы не должны возвращать ручки своим внутренним частям (см. Закон Деметры).

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

Ответ 6

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

Если право собственности является проблемой, используйте интеллектуальный указатель. Если нет, я бы использовал ссылку, если это практически осуществимо.

Ответ 7

  • Вы выделяете B при построении A.
  • Вы говорите, что B не должен оставаться снаружи. Как жизнь.
    Оба они указывают на то, что B является членом A и просто возвращает ссылочный аксессуар. Вы переоцениваете это?

Ответ 8

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

Ответ 9

Я обнаружил, что в Основных рекомендациях C++ есть несколько очень полезных советов по этому вопросу:

Использование необработанного указателя (T *) или более умного указателя зависит от того, кому принадлежит объект (чья ответственность освобождать память объекта).

своя:

smart pointer, owner<T*>

не владеть:

T*, T&, span<>

владелец <>, span <> определен в библиотеке Microsoft GSL

вот правила большого пальца:

1) никогда не используйте необработанный указатель (или не собственные типы) для передачи права собственности

2) умный указатель должен использоваться только тогда, когда семантика владения предназначена

3) Т * или владелец обозначают отдельный объект (только)

4) использовать вектор/массив/диапазон для массива

5) На мой взгляд, shared_ptr обычно используется, когда вы не знаете, кто выпустит объект, например, один объект используется многопоточностью.

Ответ 10

Когда вы говорите: "Пусть говорят, что B - это класс, который семантически не должен существовать вне времени жизни A"

Это говорит мне, что B должен логически не существовать без A, но как насчет физически существующего? Если вы можете быть уверены, что никто не будет пытаться использовать * B после A dtors, чем, возможно, необработанный указатель будет в порядке. В противном случае может оказаться целесообразным указатель.

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