В Вто, 24/03/2009 в 00:04 +0300, Artem Chuprina пишет: > Покотиленко Костик -> [email protected] @ 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, пришедшие в голову, так, чтобы более-менее покрывали > приведенные тобой категории. На perl'е я боюсь 3-х хороших не вспомню. Я их наверно просто не знаю. > >> Но почему драйвера пишут на C и почему криптографию пишут на ассемблере > >> с сишной обвязкой, хотя бы можно обосновать. Рантайм от более серьезных > >> языков там действительно слишком тяжел. А все остальное - не от > >> большого ума. > > ПК> Я тебе на это скажу так: высокоуровневым/скриптовым языкам > ПК> легко/быстро учиться, на них легко/быстро написать "первую > ПК> версию". Их программисты очень часто этим и ограничиваются. А когда > ПК> начинаешь дорабатывать, писать обработки различных ситуаций, тогда > ПК> сложность и затраченное время уравнивается. > > Не надо мне на это так говорить. Я - пробовал. Конкретно на перле. Ни > разу не уравнивается. Разница, конечно, становится поменьше - за счет > того, что скриптик "на прям щас" на перле пишется и выполняется быстрее, > чем для сишного кода запустится текстовый редактор :-). Но все равно на > порядок. Десятичный. Боюсь проверять мы не будем. Всё, кончаем эту тему. -- Покотиленко Костик <[email protected]> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
