Здравствуйте! Изучаю умные указатели и что-то совсем запутался... Вначале опишу, что мне нужно.
Есть класс Book и vector из указателей на эти книги. Вот захотелось мне, чтобы это были не обычные указатели, а умные...
1) В чём разница между shared_ptr и auto_ptr? Правильно ли я понимаю, что при auto_ptr на объект может ссылаться лишь один указатель, в то время как при shared_ptr - множество (т.к. идёт подсчёт ссылок)? При этом, если auto_ptr перестаёт указывать на объект, то он уничтожается? Ровно как и shred_ptr, когда кол-во ссылок равно 0?
2) Вернёмся к вектору. Пускай в нём 1000 умных указателей на объекты. И мне например захотелось удалить 200 объектов... Т.е. мне надо всего-лишь удалить указатели из вектора и больше ни о чём не беспокоиться?
3) Или на примере игры... есть Object и вектор из 100 Target'ов. Object имеет в себе указатель на один из Target'ов... Эти самые 100 Target'ов должны быть именно shared_ptr, т.к. на них ещё могут ссылаться из вне?
В общем, каша в голове   

если речь о векторе про ауто_птр можно сразу забыть...


не совсем..  ауто_птр владеет одним обьектом, при копировании передаёт все права с обьектом другому ауто_птр, а при разрушении удаляет обьект коим владеет.. 

Tiarwe, auto_ptr такая своеобразная штука, что лучше ей не пользоваться. Если не знаешь для чего она нужна. Сейчас ее имеет смысл использовать только для контроля времени жизни динамического объекта по типу автоматических. Хотя для этого есть (в boost) более подходящая штука - scoped_ptr. Которая ведет себя более предсказуемо без чтения документации.

Tiarwe, Читай книгу Джосьютиса "Стандартная библиотека C++". Там описан std::auto_ptr во всех красках, описаны его ограничения и его возможности, а также нюансы. После его описания в это книге приведен пример кода умного указателя с подсчетом ссылок.

Tiarwe,
Я бы юзал не вектор указателей, а список указателей. Посмотрите в сторону других контейнеров отличных от std::vector, к примеру std::list. Во внутренней реализации этого контейнера как правило участвуют указатели( не те что хранятся в этом контейнере, в контейнере может храниться любой тип хоть SuperPuperMatreshka). Обратите внимание на слово "complexity" вот список STL контейнеров

Добавлено через 1 минуту и 34 секунды
А вот другая для распечатывания на стену

EvilsInterrupt, в чём сермяжная правда отказа от вектора? Если уж так любишь ссылаться на книги, почему не привести цитату из Майерса:

За точность цитаты не ручаюсь, за смысл - да

      

Почитай тут все расжевано
http://www.rsdn.ru/article/cpp/smartptr.xml

Это если не знать! Вектор как правило имеет смысл выбирать если нужно непрерывную область, так сказать C-стайл, сейчас его вроде как std::array может заменить в этом, судя по описанию на cppreference.

Более того в постановке задачи:

и:


Ни одного намека на то что человеку нажно хранить книги в С-подобном виде, т.е. последовательно в файле. Зато указано 1000 !!!! Т.е. человек предполагает что ему надо будет достаточно часто вставлять. Другое из постановки задачи:


Вы все еще уверены в векторе? Удалить 200 штук, добавить 1000...

1) то, что в векторе память непрерывная - спорить глупо, но его чаще выбирают по другим причинам (правда, являющимся следствием непрерывности) - random acces за постоянное время и т.п.
2) std::array заменил массивы типа

а ни разу не вектор


По поводу добавить - уверен:
http://liveworkspace.org/code/2eY9uN$9
По поводу удалить - подумай во над чем: прежде чем удалить элемент из контейнера его нужно там найти. Тест поиска элемента в векторе и в листе написать ? или и так понятно ?

borisbn, 
Вы правы! Спасибо за аргументацию, которую можно "пощупать" и "потрогать". Нельзя мне в 2 ночи посты писать, каюсь! ;)

и это еще .reserve не использован ))

справедливости ради надо отметить, большая разница, вставлять в конец или в начало.. 

Если честно меня удивляет, почему разработчики STL не сделали такую простую штуку, как возможность добавлять в начало вектора с такой же сложностью, как и в конец. Реализуется это всего лишь одним дополнительным указателем внутри класса и тройкой методов (reserve_front(), push_front(), pop_front()).

vector должен быть непрерывным от &v[0]

Добавлено @ 14:47
есть же deque<>, тут вам и такая же временная сложность, и добавление в начало.
лишь непрерывность не гарантирована

Это сообщение отредактировал(а) baldina - 29.1.2013, 14:47

А кто мешает? Просто сейчас добавление в начало всегда приводит к сдвигу всех элементов, а в случае с дополнительным указателем - сдвигалось бы только начало массива (если резерв перед данными есть):главное условие: area_beg_ <= data_beg_ <= data_end_ <= area_end_
Если data_end_ == data_beg_, то вектор пуст
Если area_end_ == area_beg_, то вектор не имеет резерва (и пуст).
Если area_beg_ < data_beg_, то у вектора есть резерв перед началом
Если data_end_ < area_end_, то у вектора есть резерв после конца

Таким образом, сложность добавления в начало была бы равна сложности добавления в конец.