Я не Анатолий, ручки не сложу Сначала про new
а это вывод от задачи скомпилированной gcc (3.4.5)
Это камешек в огород Visual C ну не стандартный он. Так что на Unix вас ждет масса сюрпризов:-))) Специально залез в Язык программирования C++ Бьерн Страусструп Специальное издание п 6.2.6.2
Что касается кода который я привожу? не надо воспринимать его буквально от а-я. Это всего лишь попытка смоделировать ситуацию, не более того. ( см ). Я просто пытался показать что происходит если генерацию исключения и его обработку разделяют несколько уровней вложенности в которых также динамически создаются объекты.
Теперь на счет auto_ptr. Люблю я людей рассуждающих о вкусе устриц не разу их не попробовав. Хоть бы из любопытсва взяли и посмотрели что это. Ну ладно коротенько перескажем это маленький шаблон - обертка(proxy) вся задача которого отслеживать время жизни указателя. У него масса недостатков. и одно гигантское достоинство - он стандартный.
А что касается кривизны кривизны моих рук и не знания что делать выданным мне инструментом. Ну это по крайней мере безосновательно

Aklin blinded

для gcc есть рабочий free и calloc(malloc).
что касается того что я не пробовал auto_ptr вы глубоко залуждаетесь, провел два часа в этой беседе и пока не понял никаких плюсов, зато написал (см. выше) "запутанный код" и "неконтролируемость".
Ну мы же не на С свами пишем. Да и отделение выделения памяти от вызова конструктора ни к чему хорошему не приведет,
Ну что до запутанности кода и неконтролируемости - это вы не научились им подьзоваться. Кстати должен вас огорчить, в грядущий стандартбудет включено несколько новых smart указателей.

Aklin Sandro_K
подыдожу, что бы все поняли, о чем идет речь
1) те, кто используют auto_ptr не знают что это : интерфейсм или затычка
2) кто-то сказал, что это манагер. я уже говорил, что собственные манагеры быстрее, понятней и удобней
3) контроль над программой падает.

также мне интересен вопрос о переносу указателей через третьи руки.
скажем
a=new
b=a
c=b
причем c из другой функции.
что на это ответит auto_ptr ?
1) а что вы понимаете под одним и другим. А по научному это называется proxy
2) ну вообще-то под менеджером памяти понимается отличное от того о чем вы сдесь говорили. тот пример ErV это не менеджер памяти - это proxy. Ну то что они понятней - это смотря кому, автору - да, тем кто его использует в темную - нет. И в этом отношении я отдам предпочтение стандартному классу.
3) интересно что подумает ваш приемник, когда увидит ваш доморощенный proxy написанный под конкретный случай?
А насчет указателей там все просто
Неужто так сложно ?

ErV blinded Неужто так сложно ?
На мой взгляд очень неудобно, и не стоит использовать по следующей причине:
1) Нарушает стандартное поведение операторов C++. Я думаю, что любого нормального программера повергнет в изумлеение, если в выражении int i = 3; int a = i; printf("i: %d, a: %d",i,a); i к моменту вызовва printf будет равно нулю. Именно это делает auto_ptr;
2) вы выше показали пример, в котором используется auto_ptr. Получается, что auto_ptr нельзя присвоить "не auto_ptr" указатель. Для меня, например, это был бы довольно логичный вариант инициализации. По-моему, это недочет убивает все его достоинства (которых я так особо и не улицезрел) - вместо нормального указателя получается помесь указателя, ссылки и локальной переменной... Память в момент присваивания было бы не так уж сложно высвободить.
3) чтобы решить проблемы с забытыми массивами, может тогда уже сразу заюзать смарт-поинтеры? Нормально реализованные, которые бы поддерживали подсчет ссылок на область, и динамически создавали бы дубликат исходного вариант области при попытке доступа к ней на запись. Вот этот вариант я ещё могу понять.
Кстати, что вам мешает с auto_ptr сделать вот это:
Это уже поинтересней утечки памяти...
1)Да несколько непривычно, вот только надо внимательнее смотреть на сигнатуру у всех
SomeClass& operator=(const SomeClass&);
а у этого она иная
SomeClass& operator=(SomeClass&)
ну так это проблема довольно распространенная.
2)это почему же нельзя, вот так все правильно
Причина - конструктор auto_ptr<T>::auto_ptr(T*) - объявлен как explicit
3) Да ктобы спорил что быть счастливым и богатым лучше чем бедным и больным. Одна беда нестандартные они, знаешь как донимает когда у тебя несколько сторонних пакетов, в каждом из которых свой smart pointer? Вот примут C++0x полегчаетю А вот создание дубликата это вообще-то не семантика указателя. Да и что делать с опретором -> он ведь не указатель на константный объект, а вот читать лм вы будете или писать не ясно. Да и подсчет ссылок это уже не что-то невесомое, особенно в многопоточной задачке. (хотя опять же готов пойти на жертвы)
А что касается segmentation violation, это да, это плохо. Но это вопрос исторический. Это гуру напутали, а потом решили что так правильнее, чем ошибки в стандартных алгоритмах