Re: Функционал и интерфейс
В Вто, 24/03/2009 в 00:04 +0300, Artem Chuprina пишет:
> Покотиленко Костик -> 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, пришедшие в голову, так, чтобы более-менее покрывали
> приведенные тобой категории.
На perl'е я боюсь 3-х хороших не вспомню. Я их наверно просто не знаю.
> >> Но почему драйвера пишут на C и почему криптографию пишут на ассемблере
> >> с сишной обвязкой, хотя бы можно обосновать. Рантайм от более серьезных
> >> языков там действительно слишком тяжел. А все остальное - не от
> >> большого ума.
>
> ПК> Я тебе на это скажу так: высокоуровневым/скриптовым языкам
> ПК> легко/быстро учиться, на них легко/быстро написать "первую
> ПК> версию". Их программисты очень часто этим и ограничиваются. А когда
> ПК> начинаешь дорабатывать, писать обработки различных ситуаций, тогда
> ПК> сложность и затраченное время уравнивается.
>
> Не надо мне на это так говорить. Я - пробовал. Конкретно на перле. Ни
> разу не уравнивается. Разница, конечно, становится поменьше - за счет
> того, что скриптик "на прям щас" на перле пишется и выполняется быстрее,
> чем для сишного кода запустится текстовый редактор :-). Но все равно на
> порядок. Десятичный.
Боюсь проверять мы не будем. Всё, кончаем эту тему.
--
Покотиленко Костик <casper@meteor.dp.ua>
Reply to: