std::auto_ptr<...> tmp(new ...);

Detected memory leaks!
Dumping objects ->
c:\dir : {70} normal block at 0x01062828, 164 bytes long.

Возможно это? Или внутри типа утечка?

автоуказатели не гарантируют отсутвия течей. Может течь внутри класса - запросто, а может еще где-то. Есть инструменты вроде valgring - умеют показывать "кто плохой". Попробуйте.

а ещё стоит обратить вниманием на предупреждения
бывают случаи, когда std::auto_ptr не вызывает деструкторы: когда при его использовании доступно только объявление класса, как типа, без внутренностей
в таких случаях компилятор (по крайней мере, VC++ 2005) выдаёт предупреждение "деструктор не будет вызван"

Там случайно не "operator new []"?

нет

Не помню где, но где-то точно, читал что комитет по стандартизации не рекомендует auto_ptr к использованию. Могу порекомендовать воспользоваться boost::shared_ptr.

Это сообщение отредактировал(а) Леопольд - 27.6.2009, 10:47

Майерс в каждом втором совете об этом пишет 

Повторяется  

Почему не использовать его для автоудаления объекта после выхода за пределы области видимости? boost::shared_ptr несколько тяжеловесный для этого.

lv151, 
Если не желаешь пользоваться профилировщиком, попробуй измени объект (создай в нем, в к примеру, массив-член класса char-ов на 10000 элементов. )
Если строчка

изменится, значит, это твой объект не удаляется.

А std::auto_ptr не слишком "тяжёлый" для этой задачи?  Можно просто воспользоваться самописным...

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

Проблема, насколько я помню, в том что std::auto_ptr передаёт владение объектом, и может передать "владение" временному std::autp_ptr (например, если аргумент функции передаётся по значению...) после "смерти" которого автоудалится "завёрнутый" объект.

Это сообщение отредактировал(а) Леопольд - 28.6.2009, 00:52

Ещё хотелось бы добавить что причина скорее всего не в auto_ptr а в неправильном его применнии. Вот пример утечки. Знаете почему здесь утечка?


Это сообщение отредактировал(а) Леопольд - 27.6.2009, 21:20

...Удалено по просьбе Леопольда...

Это сообщение отредактировал(а) mes - 27.6.2009, 23:17

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

Удалите, пожалуйста, ответ, пока топикпастер не увидел...

Это сообщение отредактировал(а) Леопольд - 27.6.2009, 23:12

Вот специально влез в STL и посмотрел. Вся его реализация - один приватный указатель и несколько легких методов, каждый из которых компилируется, только если реальная нужда в них есть.
boost::shared_ptr состоит как минимум из переменной и указателя. (На самом деле там еще внутренняя структура).


Иногда объект A принимает указатель на другой объект B, который потом уничтожает сам. Этот объект нужно создать в куче и настроить:

Все проблемы устраняются одним std::auto_ptr.
Пример ни разу не надуманный.

Это сообщение отредактировал(а) hsilgos - 28.6.2009, 00:19

Ладно, он не тяжёлый. Всё скорее всего встроится в место вызова. Как и в случае с моим кустарным классом, который, как минимум прозрачен а накатал я его за 5-10 минут. В его имени так же не содержится сокращённое слово pointer.  Сразу хочу заметить, что тем, кто рассчитывает только лишь на "некривое" использование их кода, не стоит писать библиотек массового потребления. Некоторые пассатижами забивают гвозди. Сам видел, да и забивал тоже 

Я не пользуюсь auto_ptr по причине его неинтуитивности. Думаю все согласятся что следующий код не выглядит ошибочным (если знать только то, что auto_ptr "подчищает хвосты"), но это не так:

Это и есть его основная проблемма.


Если мне понадобится автоуборка то я лучше напишу вот так:




Либо объект действительно большой и в стек никак не влезет (100 мегабайт, например), либо используется глубокая рекурсия (хотя здесь я этого не увидел), и таких объектов может быть очень много. Ещё есть смысл создавать объекты в куче, если ты пишешь "фабрику", но это не наш случай... Если же размер такого локального объекта пару сотен килобайт (а может и пару мегабайт), то я лучше увеличу размер стека. Конечно, всё это при условии, что функция вызывается достаточно часто, что-бы это имело смысл.

Это сообщение отредактировал(а) Леопольд - 28.6.2009, 02:13