Идиоматическое использование std :: auto_ptr или только использование shared_ptr?

Question

Теперь, когда shared_ptr находится в tr1, что, по вашему мнению, должно произойти с использованием std::auto_ptr? Они оба имеют разные варианты использования, но все варианты использования auto_ptr могут быть решены также с помощью shared_ptr. Вы откажетесь от auto_ptr или продолжите использовать его в тех случаях, когда вы хотите явно указать, что только один класс имеет право собственности в любой заданной точке?

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

Что вы думаете об этом?

Answer 1

auto_ptr также хорош в подписи. Когда функция принимает значение auto_ptr<T>, это означает, что она будет использовать T. Если функция возвращает auto_ptr<T>, ясно, что она отказывается от владения. Это может сообщить ваши намерения о жизни.

С другой стороны, использование scoped_ptr<T> подразумевает, что вы не хотите заботиться о времени жизни T. Это также означает, что вы можете использовать его в большем количестве мест. Оба интеллектуальных указателя являются допустимыми вариантами, вы, безусловно, можете использовать оба в одной программе.

Answer 2

Чтобы предоставить немного больше боеприпасов для лагеря 'избежать std::auto_ptr': auto_ptr устарело в следующем стандарте (C ++ 0x). Я думаю, что одного этого патрона достаточно для любого аргумента, чтобы использовать что-то еще.

Однако, как упоминал Конрад Рудольф , замена по умолчанию для auto_ptr, вероятно, должна быть boost::scoped_ptr. Семантика scoped_ptr более точно соответствует семантике auto_ptr, и она предназначена для аналогичного использования. Следующий стандарт C ++ 09 будет иметь нечто подобное, называемое unique_ptr.

Тем не менее, использование shared_ptr везде, где следует использовать scoped_ptr, ничего не сломает, просто добавит немного неэффективности, чтобы справиться со счетчиком ссылок, если объект никогда не будет совместно использоваться. Так что для частных указателей, которые никогда не будут переданы другому объекту - используйте scoped_ptr. Если указатель будет передан другому объекту (это включает в себя его использование в контейнерах или все, что вы хотите сделать, это передать право владения, а не сохранить или поделиться им) - используйте shared_ptr.

Answer 3

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

Если вам не нужно совместное владение, shared_ptr является излишним: ему нужно выделить отдельный блок памяти для подсчета ссылок, что может повлиять на производительность, и это менее понятно с точки зрения документации.

Лично я использую std::auto_ptr во многих местах, где boost::scoped_ptr также будет достаточно: например, удержание выделенного в куче объекта перед передачей права собственности в другое место, куда могут перебраться промежуточные операции.

C ++ 0x будет иметь std::unique_ptr для дополнения std::shared_ptr в качестве лучшей альтернативы std::auto_ptr. Когда он станет широко доступным, я начну его использовать.

Answer 4

Я полагаю, что наилучшей практикой является замена всех вариантов использования std::auto_ptr на boost::scoped_ptr, если std::tr1::shared_ptr не отвечает требованиям лучше, , если , вы не против используя Boost. С другой стороны, это было преднамеренно, что scoped_ptr не было включено в TR1.

Answer 5

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