Re: Функционал и интерфейс
В Пнд, 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' было бы легче.
>
> На перле, кстати, тоже иногда подобные танцы приходится устраивать. По
> счастью, редко.
Вот тебе и доля правды о "шило на мыло".
--
Покотиленко Костик <casper@meteor.dp.ua>
Reply to: