Re: Функционал и интерфейс
Покотиленко Костик -> debian-russian@lists.debian.org @ Fri, 20 Mar 2009 13:50:42 +0000:
>> >> >> И на каждое выделение памяти. Вверх по всему стеку вызовов.
>> >>
>> >> ПК> Если не увлекаться вызовом malloc() inline, а каждый "объект"
>> >> ПК> делать набор функций create, destroy и т.д. то это не много и
>> >> ПК> оправдано. Кстати, разделяя функционал от интерфейса и выделив
>> >> ПК> библиотеку, так даже проще.
>> >>
>> >> Любая попытка выделить память может закончиться неудачей. И называется
>> >> она malloc() или create - рояля не играет. Ну, с точностью еще до
>> >> классических грабель "объективизации" конструкции, описанных во всех
>> >> книжках по C++ - "что будет, если ошибка произойдет в момент, когда
>> >> память выделена под _часть_ подобъектов?"
>>
>> ПК> Если ты программист Си - решать тебе что будет.
>>
>> Не вопрос. Но существует только один приемлемый способ решения -
>> аккуратно очистить все, что успело выделиться до этого момента. В
>> случае с C - вручную отследив, что же успело выделиться.
ПК> Что значит успело выделиться? Само оно не выделяется, по крайней
ПК> мере в Си.
На примере gtk.
Как ты создаешь композитный виджет? Создаешь внутренние, и делаешь им
add. По очереди. Если у тебя обломалость по недостатку памяти создание
второго внутреннего виджета, ты перед возвратом должен только прибить
внешний. А вот если обломался его add, то удаления внешнего для
освобождения памяти внутреннего недостаточно - он же не добавился. Надо
его destroy вручную. И так с каждым.
>> Нет, тут тоже
>> существует обходной маневр. Ценой определенной дисциплины организации
>> функций, пары-тройки макросов для поддержки оной дисциплины и нескольких
>> дополнительных строчек на каждое выделение.
ПК> Так и получается когда программист не знает "как оно
ПК> работает". Тогда да, и само выделяется, и выслеживать надо.
А, ты предпочитаешь просто забить на утечки памяти? Здравствуй, Mozilla
firefox... Они, видимо, тоже. В результате его больше трех суток без
перезапуска держать, гм, не рекомендуется.
>> ПК> Мне, например, не нравится как такие ситуации отработал
>> ПК> spamassassin написанный на perl. Смотри тред "OOM-Killer". С
>> ПК> perl'ом даже OOM-Killer не справился.
>>
>> А это - проблема, перпендикулярная. Если тебе в сишной программе
>> понадобилась память - ты ее точно так же будешь запрашивать.
ПК> Один раз, потом верну ошибку назад по стеку, там пусть решают что
ПК> делать.
А там пожмут плечами и начнут следующую итерацию главного цикла. В
которой снова запросят память...
>> ПК> У Perl'а своя ниша, и он хорош пока от туда не вылазит.
>>
>> Не вопрос. Она у него даже малость поуже, чем у C. Проблема в том, что
>> C из своей ниши вылазит...
ПК> Посмотрим что успешно пишут на Си: драйвера, демоны, серверные,
ПК> клиентские, десктопные приложения, и т.д.
То-то у меня ipw2200 не работает больше полутора суток, firefox через
неделю работы приходится прибивать kill -9, потому что на штатное
завершение ему получаса не хватает, а у тебя snmpd жрет 10% CPU...
Но почему драйвера пишут на C и почему криптографию пишут на ассемблере
с сишной обвязкой, хотя бы можно обосновать. Рантайм от более серьезных
языков там действительно слишком тяжел. А все остальное - не от
большого ума.
>> >> Ты на sh тоже как на C пишешь? (Там, впрочем, если писать аккуратно,
>> >> это бывает оправдано...)
>>
>> ПК> А это как?
>>
>> command
>> if [[ $? == ... ]]; then
>> ...
>> fi
>>
>> И т.п. Это если "как писать". Если "когда оправдано" - вместо пайпов
>> использовать временные файлы, потому что классический sh умеет вернуть
>> код только последней команды в пайпе, успех завершения остальных
>> проверить невозможно. В bash или zsh можно, но тоже очень
>> небесплатно... (На самом деле сейчас придет Чеусов и скажет, что на
>> классическом sh тоже можно - но ты попроси его тогда этот код показать,
>> он у него, кажется, есть...)
ПК> Иногда приходится и так писать. Спорить не буду, на perl' было бы легче.
На перле, кстати, тоже иногда подобные танцы приходится устраивать. По
счастью, редко.
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
Хакинг и кракинг ульев с последующим чавкингом мёда, безусловно, является злым
розыгрышем. Особенно с точки зрения пасечника.
-- http://knjazna.livejournal.com/44647.html?thread=630375#t630375
Reply to: