Отпустить auto_ptr - PullRequest
       8

Отпустить auto_ptr

5 голосов
/ 26 января 2011

Иногда, в мимолетные моменты, я думаю, что auto_ptr - это круто.Но большую часть времени я признаю, что есть намного более простые методы, которые делают это неуместным.Например, если я хочу автоматически освободить объект, даже если выдается исключение, я могу создать новый объект и назначить auto_ptr.Очень круто!Но я мог бы проще создать свой объект как локальную переменную и позволить стеку позаботиться об этом (дух!).

Таким образом, я не был слишком удивлен, когда нашел стандарты кодирования google C ++ запрет на использование auto_ptr.Google заявляет, что вместо этого следует использовать scoped_ptr (если требуется умный указатель).

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

update : для тех, кто выразил обеспокоенность, нет, я не принимаю стандарты Google.Например, вопреки совету Google, я согласен, что обработка исключений должна быть активирована.Мне также нравится использовать макросы препроцессора, такие как printable enum , который я сделал.Меня поразила только тема auto_ptr.

update2 : Оказывается, мой ответ получен от двух респондентов, представленных ниже, и от заметки из Википедии .Во-первых, Херб Саттер действительно показал правильное использование (идиома источника-приемника и состав объекта, связанный с временем жизни).Во-вторых, есть магазины, в которых TR1 и boost недоступны или запрещены, и разрешен только C ++ 03.В-третьих, согласно Википедии, спецификация C ++ 0x осуждает auto_ptr и заменяет его на unique_ptr.Итак, мой ответ: используйте unique_ptr, если он доступен мне (на всех рассматриваемых платформах), иначе используйте auto_ptr для случаев, которые изображает Саттер.

Ответы [ 6 ]

7 голосов
/ 26 января 2011

Это самая простая вещь для использования, когда вам нужен ограниченный или уникальный указатель, и вы работаете в строгой среде C ++ 03 без доступа к реализации или расширению tr1.

7 голосов
/ 26 января 2011

Херб Саттер может помочь вам в этом: http://www.drdobbs.com/184403837

6 голосов
/ 26 января 2011

Хотя бан auto_ptr кажется привлекательным, но есть одна проблема:

template <typename T>
some_smart_ptr<T> create();

Чем вы замените заполнитель some_smart_ptr на

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

С другой стороны, в C ++ 03 никакая другая форма интеллектуального указателя не может обеспечить: невозможно, без семантики перемещения, предоставить то, что мы хотели бы здесь. auto_ptr или голый указатель - два логических претендента. Но тогда голый указатель подвергает вас риску утечки, если вызывающий абонент небрежен.

С C ++ 0x unique_ptr выгодно заменяет auto_ptr в любой ситуации.

3 голосов
/ 26 января 2011

std::auto_ptr все еще имеет семантику указателя, поэтому автоматические (не указательные) переменные не являются заменой. В частности, std::auto_ptr поддерживает полиморфизм и переназначение. С переменными стека вы можете использовать ссылки для полиморфизма, но ссылки не позволяют повторное назначение.

Иногда std::auto_ptr будет хорошо. Например, для реализации прыщ. Правда, в подавляющем большинстве случаев библиотека «умных указателей» boost предлагает лучший выбор для «умных указателей». Но сейчас std::auto_ptr - это стандартное решение, а умные указатели Boost - нет.

2 голосов
/ 26 января 2011

Используя auto_ptr в качестве возвращаемого значения функции, вы не будете испытывать никаких издержек копирования и никогда не будете иметь утечку памяти. std::auto_ptr<obj> foo() можно безопасно вызвать { foo(); }, а obj *foo() - нет. boost :: shared_ptr может решить эту проблему, но с более высокими издержками.

Кроме того, некоторые объекты не могут быть созданы в стеке из-за ограничений памяти: стеки потоков относительно малы. Но в этом случае лучше повысить :: scoped_ptr, поскольку он не может быть случайно выпущен.

1 голос
/ 26 января 2011

Что ж, одной из причин будет то, что scoped_ptr не подлежит копированию, поэтому его безопаснее использовать и с ним сложнее ошибатьсяauto_ptr разрешает передачу права собственности (например, передавая ему auto_ptr в качестве параметра конструктора).Если вам нужно подумать о передаче прав собственности, скорее всего, вам лучше с умным указателем вроде shared_ptr.

...