|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 04 Feb 2003 21:27:58
To : Aleksey Cheusov
Subject : Re: 386SX and RedHat_8.0
--------------------------------------------------------------------------------
.ua> <s93znph6sn5.fsf@cheusov.scnsoft.com> <20030131211357.GB537@iv.nn.kiev.ua>
.ua> <s93wukguida.fsf@cheusov.scnsoft.com>
From: Valentin Nechayev <netch@segfault.kiev.ua>
>>> Aleksey Cheusov wrote:
> AC>> Если класс создаётся и удаляется в пределах одной функции, то
> AC>> IMHO нечего его в хипе создавать. auto ничем не хуже (ну разьве
> AC>> что efence может не сработать) и избавляет от проблем с
> AC>> неожиданными exceptions. В итоге код получается пости такой же
> AC>> как в языках с garbage collector.
>> Представьте себе там не new(), а некоторую внешнюю функцию, которая
>> возвращает, например, указатель на строку.
AC> Представил. Только такой API скорее свойственен plain C,
AC> а не C++ и тогда не понятно, откуда там new возьмётся.
Я ж говорил - не new(), а get_zuka().
AC> А для подобных malloc-based Сишных API try/catch всё равно нужен.
AC> К тому же от auto_ptr было бы больше толку, если бы в нём был
AC> банальный reference counter, а не ownership indicator.
Свой аналог auto_ptr с нужными фичами делается строк в 10.
А reference counter - обычно даёт неоправданное усложнение и дополнительное
разыменование указателя на каждое обращение - и оно такое Вам надо?
AC> [skipped]
>> auto_ptr<zuka> z; ... z.reset(read_zuka()); ... z.release();
>>
>> (Я не уверен, что reset() и release() везде есть. Я их увидел в
>> SGI'шной доке. Если их нет, надо написать свой аналог.)
AC> В MSVC reset() нет, но суть не в этом.
В этом. Если там нельзя менять указатель в auto_ptr после его создания,
то нафиг такой auto_ptr сдался.
> AC>> напиши корректный clear/destructor и никогда у тебя не будет
> AC>> проблем с memory leaks.
>> Слово "никогда" здесь следует считать преувеличением.
AC> Hу да.
AC> Временные файлы после ^C остаются.
AC> tmpfile (3) - единственный способ это исправить?
AC> И вообще, какие есть способы кроме как хранить
AC> глобальный список временных файлов
AC> и писать обработчики событий.
Программа одноветочная? Если да - в обработчике SIGCHLD сделать throw.
Hа gcc3 это должно работать без проблем, на 2.95 - 2.96 - в одноветочных
должно работать.
>> Hе всё API согласовано с C++. Более того, в юниксах этого не следует
>> ожидать совсем, никогда.
AC> Это я уже понял.
AC> Даже банального extern "C" можно и не увидеть.
AC> Благо, в open source это легко исправляется.
extern "C" {
#include <zuka.h>
}
Метод рекомендован лично Страуструпом ;)
> AC>> Если pure abstract class совсем даже не pure, а совсем наоборот,
> AC>> и содержит виртуальный деструктор, то, конечно, да.
>> А что, в Вашей терминологии класс с виртуальным деструктором не
>> может быть pure abstract?
>> А если этот деструктор тоже абстрактный? Такое ведь разрешено.
AC> ^^^^^^^^^^ ^^^^^^^^^^^
AC> Ой. А что это? Приведи пример.
class zuka {
...
virtual ~zuka() = 0;
};
пробовал - работало. В реальных классах надо переопределить.
AC> Что-то я не могу этого себе представить.
AC> IMHO pure abstract class должен описывать функциональность,
AC> а не способ создания/удаления себя, т.е. деструктора там быть не должно.
Там требуется общий виртуальный деструктор, когда есть работа через указатель
на абстрактный базовый класс, описывающий интерфейс.
AC> Создание/Удаление объектов происходит, в общем случае, совсем не там,
AC> где классы могут используются.
Во-во.
> AC>> В мелкомягком COM для этого есть для этого специальная функция
> AC>> типа ReleaseInstance или как-то так с reference counter-ом
> AC>> внутри. Hу, это для того быть pure abstract.
>> Переведи. (c)
AC> А что тут переводить?
AC> За создание объектов отвечает class factory.
AC> Приложение (клиент) говорит CoCreateInstance с id
AC> и получает указатель на интерфейс.
AC> Работает с ним и в конце говорит ReleaseInstance.
AC> Количество клиентов считается и, если после вызова
AC> ReleaseInstance становится равным нулю, объект делает
AC> delete *this.
AC> Примерно так.
OK, но не вижу прямой связи с pure abstract classes.
-netch-
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
