семантические значения станд :: auto_ptr и повышение :: shared_ptr

Question

В нашем большом проекте у нас есть класс много со следующими typedef-х:

class Foo 
{ 
    public: 
    typedef std::auto_ptr<Foo> Ptr; 
    typedef boost::shared_ptr<Foo> Ref; 
    ... 
}; 
... 
Foo::Ref foo(new Foo); 
... 
doBar(foo); 
... 

с помощью них очень удобно. Но я сомневаюсь, что auto_ptr семантически близко к Ptr и shared_ptr - это то же самое, что и ref? Или следует использовать auto_ptr, так как имеет семантику передачи прав собственности?

Спасибо,

Answer 1

std::auto_ptr имеет семантику передачи собственности, но это совершенно разбитый. Если вы можете использовать boost::shared_ptr, то вы должны использовать boost::unique_ptr вместо std::auto_ptr, так как он делает то, что можно было бы ожидать. Он передает право собственности , а делает предыдущий экземпляр недействительным, что std::auto_ptr этого не делает.

Еще лучше, если вы можете использовать C++ 11, а затем переключиться на std::unique_ptr и std::shared_ptr.

Answer 2

auto_ptr устарел на C++ 11. Возможно, вы захотите прекратить использовать его и просто используйте shared_ptr. Для shared_ptr передача права собственности на присвоение отсутствует, количество ссылок на объект подсчитывается, и объект уничтожается при уничтожении последнего указателя.

Answer 3

Я считаю, что заказ - это просто номенклатура, которую кто-то использовал.
Это, вероятно, должно быть, ref для auto_ptr и ptr для shared_ptr, потому что:

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

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

Answer 4

Вы не должны использовать std::auto_ptr, его устаревшие и я считаю это опасным, тем более, когда вы скрываете его за таким общим типефом, как Ptr.

Не думаю, что это имеет смысл называть shared_ptr Ссылка, в данном случае это больше Ptr, чем auto_ptr.

EDIT: Я считаю это опасным, потому что вы можете легко его использовать, даже если вы полностью понимаете его работу, вы можете случайно его использовать, особенно если скрываете его за typedef. Хороший класс должен быть простым в использовании, и должно быть трудно использовать. Особенно с появлением unique_ptr Я не вижу никакого полезного сценария для auto_ptr.

Answer 5

Многое зависит от того, для чего они используются. А в случае Ref, что люди понимают им.В предстандартные дни я бы часто использовал typedef для Ptr для моей (инвазивной) ссылки, подсчитанной указатель; наличие такого ЬурейеЕ был, по сути, указывает, что тип поддерживает подсчет ссылок, и что он должен быть всегда динамически.

Оба std::auto_ptr и boost::shared_ptr имеют очень специальные семантика. Я бы предпочел не использовать typedefs для них, как из-за специальной семантики , так и потому что (в отличие от моего инвазивного задания подсчитанный указатель) они полностью независимы от указанного типа. Для любого данного типа вы можете использовать их или нет, так как требуется логика программы . (. Из-за его конкретной семантики, я нахожу довольно много использует для std::auto_ptr я склонен избегать boost::shared_ptr, однако, это довольно опасно.)