Покотиленко Костик -> debian-russian@lists.debian.org @ Mon, 23 Mar 2009
18:43:52 +0200:
>> >> >> >> И на каждое выделение памяти. Вверх по всему стеку вызовов.
>> >> >>
>> >> >> ПК> Если не увлекаться вызовом malloc() inline, а каждый "объект"
>> >> >> ПК> делать набор функций create, destroy и т.д. то это не много и
>> >> >> ПК> оправдано. Кстати, разделяя функционал от интерфейса и выделив
>> >> >> ПК> библиотеку, так даже проще.
>> >> >>
>> >> >> Любая попытка выделить память может закончиться неудачей. И
>> называется
>> >> >> она malloc() или create - рояля не играет. Ну, с точностью еще до
>> >> >> классических грабель "объективизации" конструкции, описанных во всех
>> >> >> книжках по C++ - "что будет, если ошибка произойдет в момент, когда
>> >> >> память выделена под _часть_ подобъектов?"
>> >>
>> >> ПК> Если ты программист Си - решать тебе что будет.
>> >>
>> >> Не вопрос. Но существует только один приемлемый способ решения -
>> >> аккуратно очистить все, что успело выделиться до этого момента. В
>> >> случае с C - вручную отследив, что же успело выделиться.
>>
>> ПК> Что значит успело выделиться? Само оно не выделяется, по крайней
>> ПК> мере в Си.
>>
>> На примере gtk.
>>
>> Как ты создаешь композитный виджет? Создаешь внутренние, и делаешь им
>> add. По очереди. Если у тебя обломалость по недостатку памяти создание
>> второго внутреннего виджета, ты перед возвратом должен только прибить
>> внешний. А вот если обломался его add, то удаления внешнего для
>> освобождения памяти внутреннего недостаточно - он же не добавился. Надо
>> его destroy вручную. И так с каждым.
ПК> Вопрос интересный:
ПК> void gtk_container_add(...);
ПК> void gtk_box_pack_start (...);
ПК> void gtk_table_attach(...);
ПК> Ни одна не возвращает результат. Варианта 2: либо добавление не
ПК> требует выделения ресурсов и обломов быть не может, либо таки об
ПК> ошибке мы и не узнаем. Прям сейчас не скажу как именно оно
ПК> работает, но на практике у меня таких обломов не встречалось. Если,
ПК> конечно, добавлять то, что заведомо реально добавить.
Мое мнение о том, что реально добавить, с мнением автора библиотеки
может и не совпасть... Ну, не знаю, конкретно в gtk, может, и
гарантированно добавляет без ошибок. Но в питоне оно у меня ухитрялось
отваливаться. Ага, по assert'у. Типа "мы ошибок не возвращаем, если
что не так - мы рушим нах всю программу". Тоже, конечно, вариант. Так
firefox и падает.
ПК> С другой стороны, даже если добавление обломается, ты об этом узнаешь
ПК> через вывод GTK-WARNING:... что при тестировании вылазит сразу.
Судя по количеству срача, которое сыплет в исходный терминал firefox,
его авторы научились обходить эту проблему :-)
>> >> ПК> Мне, например, не нравится как такие ситуации отработал
>> >> ПК> spamassassin написанный на perl. Смотри тред "OOM-Killer". С
>> >> ПК> perl'ом даже OOM-Killer не справился.
>> >>
>> >> А это - проблема, перпендикулярная. Если тебе в сишной программе
>> >> понадобилась память - ты ее точно так же будешь запрашивать.
>>
>> ПК> Один раз, потом верну ошибку назад по стеку, там пусть решают что
>> ПК> делать.
>>
>> А там пожмут плечами и начнут следующую итерацию главного цикла. В
>> которой снова запросят память...
ПК> Это вопрос логики, просто на perl'е проверки вообще суть не
ПК> популярная, если они там хотя бы есть в достаточном количестве.
Не на перле, а у криворуких программистов. На C они тоже не любят
ничего проверять. Это типа сложно...
>> >> ПК> У Perl'а своя ниша, и он хорош пока от туда не вылазит.
>> >>
>> >> Не вопрос. Она у него даже малость поуже, чем у C. Проблема в том, что
>> >> C из своей ниши вылазит...
>>
>> ПК> Посмотрим что успешно пишут на Си: драйвера, демоны, серверные,
>> ПК> клиентские, десктопные приложения, и т.д.
>>
>> То-то у меня ipw2200 не работает больше полутора суток, firefox через
>> неделю работы приходится прибивать kill -9, потому что на штатное
>> завершение ему получаса не хватает, а у тебя snmpd жрет 10% CPU...
ПК> Молодец, перечислил все 3 корявые программы на Си :)
Нет, первые 3, пришедшие в голову, так, чтобы более-менее покрывали
приведенные тобой категории.
>> Но почему драйвера пишут на C и почему криптографию пишут на ассемблере
>> с сишной обвязкой, хотя бы можно обосновать. Рантайм от более серьезных
>> языков там действительно слишком тяжел. А все остальное - не от
>> большого ума.
ПК> Я тебе на это скажу так: высокоуровневым/скриптовым языкам
ПК> легко/быстро учиться, на них легко/быстро написать "первую
ПК> версию". Их программисты очень часто этим и ограничиваются. А когда
ПК> начинаешь дорабатывать, писать обработки различных ситуаций, тогда
ПК> сложность и затраченное время уравнивается.
Не надо мне на это так говорить. Я - пробовал. Конкретно на перле. Ни
разу не уравнивается. Разница, конечно, становится поменьше - за счет
того, что скриптик "на прям щас" на перле пишется и выполняется быстрее,
чем для сишного кода запустится текстовый редактор :-). Но все равно на
порядок. Десятичный.
>> >> >> Ты на sh тоже как на C пишешь? (Там, впрочем, если писать
>> аккуратно,
>> >> >> это бывает оправдано...)
>> >>
>> >> ПК> А это как?
>> >>
>> >> command
>> >> if [[ $? == ... ]]; then
>> >> ...
>> >> fi
>> >>
>> >> И т.п. Это если "как писать". Если "когда оправдано" - вместо пайпов
>> >> использовать временные файлы, потому что классический sh умеет вернуть
>> >> код только последней команды в пайпе, успех завершения остальных
>> >> проверить невозможно. В bash или zsh можно, но тоже очень
>> >> небесплатно... (На самом деле сейчас придет Чеусов и скажет, что на
>> >> классическом sh тоже можно - но ты попроси его тогда этот код показать,
>> >> он у него, кажется, есть...)
>>
>> ПК> Иногда приходится и так писать. Спорить не буду, на perl' было бы
>> легче.
>>
>> На перле, кстати, тоже иногда подобные танцы приходится устраивать. По
>> счастью, редко.
ПК> Вот тебе и доля правды о "шило на мыло".
Дохтур, я, в отличие от Вас, знаю, когда, где, и главное, сколько. До
шила на мыло отсюда как до Луны.
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: r...@jabber.ran.pp.ru
HTTP тоже не каждый дятел может сделать. Только дятлы об этом обычно не знают.
Victor Wagner в <b9td98$d8...@wagner.wagner.home>
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
