|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 03 Feb 2003 16:54:23
To : Aleksey Cheusov
Subject : Re: 386SX and RedHat_8.0
--------------------------------------------------------------------------------
>>> Aleksey Cheusov wrote:
> VW>> Вопрос - кто в данном случае освободит динамическую память, в которой
> VW>> размещен объект foo?
> VW>> Данным называется случай, когда foo->SomeMethod выкинул exception.
>> Это штатная проблема и для неё есть штатные методы решения.
>> Hапример, auto_ptr. Идёт в стандартной библиотеке, кажется.
AC> Если класс создаётся и удаляется в пределах одной функции,
AC> то IMHO нечего его в хипе создавать.
AC> auto ничем не хуже (ну разьве что efence может не сработать)
AC> и избавляет от проблем с неожиданными exceptions.
AC> В итоге код получается пости такой же как в языках с
AC> garbage collector.
Представьте себе там не new(), а некоторую внешнюю функцию, которая возвращает,
например, указатель на строку (или, чтобы не вспоминать std::string -
на выделенный в куче объект-структуру). С полученными данными производится
несколько действий, после чего надо удалить полученное.
Таких API можно в стандартном /usr/lib увидеть уже, наверно, под сотню.
auto здесь никак не сработает.
С auto_ptr будет просто:
auto_ptr<zuka> z;
...
z.reset(read_zuka());
...
z.release();
(Я не уверен, что reset() и release() везде есть. Я их увидел в SGI'шной
доке. Если их нет, надо написать свой аналог.)
AC> А объект если создаётся и удаляется в разных функциях, то
AC> не надо поинтеры по аргументам функций тоскать, сделай его (указатель)
AC> мембером,
Я не могу найти что-нибудь такое, для чего указатель на объект будет
в этом случае мембером. Конструировать искусственные объекты - не хочу.
auto_ptr - такой естественный объект.
AC> напиши корректный clear/destructor
AC> и никогда у тебя не будет проблем с memory leaks.
Слово "никогда" здесь следует считать преувеличением.
AC> Если хочешь обеспечить хоть какой-нибудь code reuse,
AC> то возможные состояния объекта по-крайней мере держать в голове
AC> нужно и корректный clear IMHO всегда нужно писать.
AC> Т.е. auto_ptr IMHO не кассу, т.е. в кассу, но не в таких
AC> простых случаях.
Hе всё API согласовано с C++.
Более того, в юниксах этого не следует ожидать совсем, никогда.
> VW>> Этот случай, естественно, чрезмерно упрощенный. Достаточно сделать
> VW>> объект foo статическим и мусора не будет. Hо бывают и более сложные
> VW>> случаи. Hапример, если SomeOtherClass - pure abstract class,
> VW>> которому присваеивается объект одного из десятка производных классов.
>> Hу и? Виртуальный деструктор через указатель работает для любого
>> производного класса.
AC> Если pure abstract class совсем даже не pure,
AC> а совсем наоборот, и содержит виртуальный деструктор,
AC> то, конечно, да.
А что, в Вашей терминологии класс с виртуальным деструктором не может
быть pure abstract? А если этот деструктор тоже абстрактный?
Такое ведь разрешено.
AC> В мелкомягком COM для этого есть для этого специальная
AC> функция типа ReleaseInstance или как-то так с reference counter-ом внутри.
AC> Hу, это для того быть pure abstract.
Переведи. (c)
-netch-
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
