В Пнд, 23/03/2009 в 18:26 +0300, Artem Chuprina пишет: > Покотиленко Костик -> 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 вручную. И так с каждым.
Вопрос интересный: void gtk_container_add(...); void gtk_box_pack_start (...); void gtk_table_attach(...); Ни одна не возвращает результат. Варианта 2: либо добавление не требует выделения ресурсов и обломов быть не может, либо таки об ошибке мы и не узнаем. Прям сейчас не скажу как именно оно работает, но на практике у меня таких обломов не встречалось. Если, конечно, добавлять то, что заведомо реально добавить. С другой стороны, даже если добавление обломается, ты об этом узнаешь через вывод GTK-WARNING:... что при тестировании вылазит сразу. > >> Нет, тут тоже > >> существует обходной маневр. Ценой определенной дисциплины организации > >> функций, пары-тройки макросов для поддержки оной дисциплины и нескольких > >> дополнительных строчек на каждое выделение. > > ПК> Так и получается когда программист не знает "как оно > ПК> работает". Тогда да, и само выделяется, и выслеживать надо. > > А, ты предпочитаешь просто забить на утечки памяти? Ни в коем случае. > >> ПК> Мне, например, не нравится как такие ситуации отработал > >> ПК> spamassassin написанный на perl. Смотри тред "OOM-Killer". С > >> ПК> perl'ом даже OOM-Killer не справился. > >> > >> А это - проблема, перпендикулярная. Если тебе в сишной программе > >> понадобилась память - ты ее точно так же будешь запрашивать. > > ПК> Один раз, потом верну ошибку назад по стеку, там пусть решают что > ПК> делать. > > А там пожмут плечами и начнут следующую итерацию главного цикла. В > которой снова запросят память... Это вопрос логики, просто на perl'е проверки вообще суть не популярная, если они там хотя бы есть в достаточном количестве. > >> ПК> У Perl'а своя ниша, и он хорош пока от туда не вылазит. > >> > >> Не вопрос. Она у него даже малость поуже, чем у C. Проблема в том, что > >> C из своей ниши вылазит... > > ПК> Посмотрим что успешно пишут на Си: драйвера, демоны, серверные, > ПК> клиентские, десктопные приложения, и т.д. > > То-то у меня ipw2200 не работает больше полутора суток, firefox через > неделю работы приходится прибивать kill -9, потому что на штатное > завершение ему получаса не хватает, а у тебя snmpd жрет 10% CPU... Молодец, перечислил все 3 корявые программы на Си :) > Но почему драйвера пишут на C и почему криптографию пишут на ассемблере > с сишной обвязкой, хотя бы можно обосновать. Рантайм от более серьезных > языков там действительно слишком тяжел. А все остальное - не от > большого ума. Я тебе на это скажу так: высокоуровневым/скриптовым языкам легко/быстро учиться, на них легко/быстро написать "первую версию". Их программисты очень часто этим и ограничиваются. А когда начинаешь дорабатывать, писать обработки различных ситуаций, тогда сложность и затраченное время уравнивается. > >> >> Ты на sh тоже как на C пишешь? (Там, впрочем, если писать аккуратно, > >> >> это бывает оправдано...) > >> > >> ПК> А это как? > >> > >> command > >> if [[ $? == ... ]]; then > >> ... > >> fi > >> > >> И т.п. Это если "как писать". Если "когда оправдано" - вместо пайпов > >> использовать временные файлы, потому что классический sh умеет вернуть > >> код только последней команды в пайпе, успех завершения остальных > >> проверить невозможно. В bash или zsh можно, но тоже очень > >> небесплатно... (На самом деле сейчас придет Чеусов и скажет, что на > >> классическом sh тоже можно - но ты попроси его тогда этот код показать, > >> он у него, кажется, есть...) > > ПК> Иногда приходится и так писать. Спорить не буду, на perl' было бы легче. > > На перле, кстати, тоже иногда подобные танцы приходится устраивать. По > счастью, редко. Вот тебе и доля правды о "шило на мыло". -- Покотиленко Костик <cas...@meteor.dp.ua> -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
