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

Не будет утечки памяти. Тут будет следующая коснтрукция:




Ну конечно, лучше использовать свой велосипед. Он ведь свой, родной   


Да нет же... Вот, к примеру, в wxWidgets есть набор классов для работы с XML.
Там документ можно и нужно создавать статически, а "ветви" ему уже нужно подсовывать созданные в куче. Он их затем сам удаляет.
И многие вещи так работают: иерархии классов окошечных классов во многих гуишных библиотеках и пр...

удалил чтоб' не позориться... 


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

Да с чего ж вы решили, что здесь будет меморилик? Не будет.
Объект класса Modify возьмет владение объектом и при завершении функции благополучно освободит память.


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

Добавлено через 1 минуту и 52 секунды
Я ведь не говорю о тотальном использовании shared_ptr ? Каждому инструменту - своё место. shared_ptr - у место для простейшего автоосвобождения.

Ошибся, утечки не будет. Но я уверен что тот кто это написал бы  не ожидает что это удалит объект, изначально выделенный на ptr0...

Дело в том что это не велосипед, и даже не педаль от него. Они сложнее устроены... Можно разобраться в auto_ptr, а можно использовать свой примитив. На самом деле, второй вариант даже быстрее и меньше шансов что поймёшь его немножко неправильно. 

Добавлено @ 02:42

Что то я и правда туплю... :(

Добавлено @ 02:42
Но всё равно, auto_ptr работает не интуитивно! 

Добавлено @ 02:47

Это не те функции которые вызываются 90% времени работы программы, я прав? 

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

Что да, то да. Я его и не использую для серьезных задач.
Однако чтобы не плодить try/catch и не копипастить освобождение ресурсов во всех точках выхода из функции auto_ptr работает замечательно.
И для его успешного применения достаточно знать минимум: передача владения и reset/release.
Кода становится меньше и понятнее. Несмотря на неочевидность auto_ptr   

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

да, спать уже пора. Голова думает одно, а руки по-привычке набирают другое  

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

Если у своего примитива та же политика удаления, то писать его еще менее интуитивно, 
так как вместо того чтоб использовать общеизвестный инструмент, у которого есть документация, Вы предлагаете отвлекать программиста на написание/изучение "примитива".
Даже если это и занимает 5 минут - лучше потратить это время на изучение std::auto_ptr. 
Или вас не устраивает название ? так на крайний случай просто замените имя : typedef std::auto_ptr  auto_delete
(хотя это тоже путь в сторону)


Не нравятся такие конструкции ? правильно. Но это не проблема auto_ptr, a программиста который такое написал 

Честно говоря, я не понял о чём речь...

Добавлено @ 18:54

Дело в том что этот примитив запрещает копирование и т.д. Т.е. программист не сможет использовать его не по назначению - авто чистка памяти. Им нельзя пользоваться как указателем, это примитивный уборщик мусора. Мне кажется что этого описания достаточно для безошибочного использования. Конечно, при условии что программист понимает как создаются и разрушаются локальные объекты. А вот с auto_ptr надо помнить что нельзя с ним делать, а что можно. Это конечно не проблема, но всё равно, лучше помнить что-то другое 
Время, которе будет потрачено на осмысление его функции измеряется в секундах. Это писал я его 5 минут... 

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

Почему нельзя что-то делать с auto_ptr? Можно! Более того, я так понимаю, он и создан для этого.Просто у каждого инструмента свое назначение. Проблема только в том, что документацию никто не читает. И не запоминает главных особенностей. С другой стороны, у этого шаблона есть недостаток при таком использовании - неочевидность. Лично я его использую именно как авто-освобождение и удобный менеджер объектов. Т.е. я делаю reset не заботясь о том, содержит автопоинтер что-то или нет.
Кстати, по моему в boost есть более подходящая вещь - scoped_ptr. Я правда не изучал его, но подозреваю, что это то, что нужно.

Это сообщение отредактировал(а) bsa - 28.6.2009, 23:41

Никто не говорит что нельзя. Можно пользоваться MFC а не wxWidgets (предположим что целевая платформа исключительно Win), но на мой взгляд wxWidgets лучше спроектирован и удобнее в использовании. Дело вкуса.

Я тоже так думаю, что для целей авточистки можно найти что-то более подходящее чем auto_ptr... 

Добавлено через 14 минут и 8 секунд
scoped_ptr (scoped_array) действительно то что надо. Он делает то-же самое что и мой кустарный класс, только больше  К тому же, есть документация...

auto_ptr советует использовать Брюс Эккель.
И вобще, смысл пихать в stl auto_ptr если он лажа?


Это сообщение отредактировал(а) lv151 - 29.6.2009, 10:47

из учебника "Философия С++"? страницу не подскажите?

не поленился перенабрать с книжки "Язык программирования С++. Вводный курс. 4 издание" (Липпман)

Ограничения класса auto_ptr
Шаблон класса auto_ptr предоставляет удобный и безопасный способ работы с объектами, размещенными в динамически распределенной памяти. Чтобы правильно использовать класс auto_ptr, следует жестко придерживаться ограничений, которые налагает этот класс.

• Не используйте класс auto_ptr для хранения указателя на статический объект. В противном случае, при удалении объекта класса auto_ptr, он попытается удалить указатель на объект, размещенный не в динамической памяти, что приведет к непредсказуемым последствиям.
• Никогда не используйте два объекта класса auto_ptr для хранения адреса того же объекта. Как правило, эта ошибка происходит в случае, Когда тот же указатель используется ри инициализации двух разных объектов класса auto_ptr или применении функции reset(). Эту ошибку можно совершить косвенно, при использовании результата выполнения функции get() одного объекта класса auto_ptr при инициализации другого, или при его передаче функции reset() другого объекта класса auto_ptr
• Не используйте объект класса auto_ptr для хранения указателя на массив в динамически распределяемой памяти. При удалении объекта классса auto_ptr он использует обычный оператор delete (который освободит только первый элемент массива), а не оператор delete[], способный удалить весь массив.
• Не сохраняйте объекты класса auto_ptr в контейнере. Контейнеры требуют, чтобы классы хранимых в них объектов обладали функциями копирования и присвоения, которые ведут себя аналогично функциям встроенных типов. После копирования (или присвоения) оба объекта должны иметь одинаковое значение. Класс auto_ptr этому требования не удовлетворяет.

Практическое программирование, с 40.

  Использовать везде и всегда будет неправильным. Это всего одна из стратегий владения, когда один владеет, он же и уничтожает, при этом владелец должен уничтожаться последним. auto_ptr удобен при передаче объекта как посылки, как сообщения другому объекту. Т.е. передал объект вместе с правами владения или вернул из функции с правами владения. Он не годиться в случае если время жизни объекта заранее не определено и имеются несколько ссылок на него. При использовании auto_ptr "просто так", всегда есть шанс что сделаешь прямое присвоение объектов и потеряешь экземпляр. 
  

Проблема вот в чём.



Удаляются только указатели на функции, но адреса in1, in2 нет.

Может быть утечка памяти по причине того, что деструктор в классах IInterface2 и IInterface1 невиртуальные (так как обьекты удаляются по указателю базового класса).

еще здесь есть неявно созданные конструктор копирования и оператор присваивания, при вызове которых произойдет утечка памяти

Обратная совместимость. Нельзя что-то просто убрать из STL если это уже там есть. Кстати, книжку он в каком году написал? 

И я не говорил что он лажа. Просто при работе с ним надо быть осторожным, а где-то он наверняка может оказаться полезным, ну а в STL контейнерах его просто нельзя использовать. Со scoped_ptr/_array не надо быть таким осторожным. shared_ptr идеально подходит для STL контейнеров... Их наверняка можно использовать криво, правда для этого уже надо будет извратиться... скорее всего  Я не хочу над этим раздумывать, пустая трата времени, но сходу придумать, как их подломать, не могу.

Добавлено @ 17:27

Здесь не только утечка, ещё и undefined behaviour может быть из-за MyClass::MyClass(const MyClass&); и MyClass& MyClass::operator= (const MyClass&); Например, при передаче по значению как аргумент функции, память (видимо частично) будет освобождена, после смерти этой копии. Потом она будет освобождена ещё ровно столько раз, сколько копий объекта было создано.

А на вопрос (27.6.2009, 21:19) так и нет ответа, к сожалению. 

Это сообщение отредактировал(а) Леопольд - 29.6.2009, 17:51

Для того чтобы понять в чём ещё проблема, кроме не объявленного оператора присваивания и конструктора копирования по умолчанию, надо посмотреть на объявления IInterface1 и IInterface2

Добавлено @ 17:47

Я случайно придумал!!! 

Не каждый додумается так непреднамеренно ошибиться. Если только с очень большого бодуна. А если не пьёт, то шансы почти нулевые 

Это сообщение отредактировал(а) Леопольд - 29.6.2009, 17:55

А еще можно явно вызвать деструктор статического или временного объекта 
Собственно для того и придумали чтобы можно было писать так

Зачем иметь 2е переменные в одной области видимости? 

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


Создал отдельную тему http://forum.vingrad.ru/forum/act-ST/f-92/...2/unread-1.html

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