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




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


Да нет же... Вот, к примеру, в 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.