|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Cheusov 2:5020/400 04 Feb 2003 20:24:15
To : Valentin Nechayev
Subject : Re: 386SX and RedHat_8.0
--------------------------------------------------------------------------------
Valentin Nechayev <netch@segfault.kiev.ua> writes:
> >>> Aleksey Cheusov wrote:
>
> > VW>> Вопрос - кто в данном случае освободит динамическую память, в
> > VW>> которой размещен объект foo? Данным называется случай, когда
> > VW>> foo->SomeMethod выкинул exception.
> >> Это штатная проблема и для неё есть штатные методы решения.
> >> Hапример, auto_ptr. Идёт в стандартной библиотеке, кажется.
> AC> Если класс создаётся и удаляется в пределах одной функции, то
> AC> IMHO нечего его в хипе создавать. auto ничем не хуже (ну разьве
> AC> что efence может не сработать) и избавляет от проблем с
> AC> неожиданными exceptions. В итоге код получается пости такой же
> AC> как в языках с garbage collector.
>
> Представьте себе там не new(), а некоторую внешнюю функцию, которая
> возвращает, например, указатель на строку.
Представил. Только такой API скорее свойственен plain C,
а не C++ и тогда не понятно, откуда там new возьмётся.
А для подобных malloc-based Сишных API try/catch всё равно нужен.
К тому же от auto_ptr было бы больше толку, если бы в нём был
банальный reference counter, а не ownership indicator.
[skipped]
> auto_ptr<zuka> z; ... z.reset(read_zuka()); ... z.release();
>
> (Я не уверен, что reset() и release() везде есть. Я их увидел в
> SGI'шной доке. Если их нет, надо написать свой аналог.)
В MSVC reset() нет, но суть не в этом.
> AC> напиши корректный clear/destructor и никогда у тебя не будет
> AC> проблем с memory leaks.
>
> Слово "никогда" здесь следует считать преувеличением.
Hу да.
Временные файлы после ^C остаются.
tmpfile (3) - единственный способ это исправить?
И вообще, какие есть способы кроме как хранить
глобальный список временных файлов
и писать обработчики событий.
> Hе всё API согласовано с C++. Более того, в юниксах этого не следует
> ожидать совсем, никогда.
Это я уже понял.
Даже банального extern "C" можно и не увидеть.
Благо, в open source это легко исправляется.
> >> Hу и? Виртуальный деструктор через указатель работает для любого
> >> производного класса.
> AC> Если pure abstract class совсем даже не pure, а совсем наоборот,
> AC> и содержит виртуальный деструктор, то, конечно, да.
>
> А что, в Вашей терминологии класс с виртуальным деструктором не
> может быть pure abstract?
> А если этот деструктор тоже абстрактный? Такое ведь разрешено.
^^^^^^^^^^ ^^^^^^^^^^^
Ой. А что это? Приведи пример. Что-то я не могу этого себе представить.
IMHO pure abstract class должен описывать функциональность,
а не способ создания/удаления себя, т.е. деструктора там быть не должно.
Создание/Удаление объектов происходит, в общем случае, совсем не там,
где классы могут используются.
> AC> В мелкомягком COM для этого есть для этого специальная функция
> AC> типа ReleaseInstance или как-то так с reference counter-ом
> AC> внутри. Hу, это для того быть pure abstract.
>
> Переведи. (c)
А что тут переводить?
За создание объектов отвечает class factory.
Приложение (клиент) говорит CoCreateInstance с id
и получает указатель на интерфейс.
Работает с ним и в конце говорит ReleaseInstance.
Количество клиентов считается и, если после вызова
ReleaseInstance становится равным нулю, объект делает
delete *this.
Примерно так.
--
Best regards, Aleksey Cheusov.
--- ifmail v.2.15dev5
* Origin: Science Soft (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
