Re: Функционал и интерфейс
В Птн, 20/03/2009 в 16:32 +0300, Artem Chuprina пишет:
> Покотиленко Костик -> debian-russian@lists.debian.org @ Fri, 20 Mar 2009 11:52:03 +0200:
>
> >> >> >> Ну и там прочее по мелочи - "а что у нас не освободится,
> >> >> >> если вылетит ошибка вот тут?"
> >> >> >>
> >> >> >> Разумеется, без gtk_widget_destroy() или там EVP_PKEY_free()
> >> >> >> было бы совсем хреново. Но с ними - просто хреново, а не
> >> >> >> хорошо. Ну разве что "слаще репы не едал"...
> >> >>
> >> >> ПК> У меня такое бывает редко, а когда бывает - заварю чаю и
> >> >> ПК> почитаю кто кого освобождает а кто кого нет, сравню с кодом
> >> >> ПК> и всё готово, делов-то 20 минут.
> >> >>
> >> >> Начнем с того, что ты вынужден тратить время и, главное,
> >> >> внимание, на то, чтобы этих ошибок не допустить.
> >>
> >> ПК> Это культура программирования, _этому_ учиться надо.
> >>
> >> Это не культура программирования. Это культура обхода ограничений
> >> языка C. В лучшем случае. Выполнение работы, которую машина может
> >> сделать лучше, культурой программирования называть не следует.
>
> ПК> Слушай, давай на примерах? А то как-то размыто. Я буду рад
> ПК> признать, что Си неэффективен, если наглядно покажешь.
>
> C эффективен. В своей узкой нише. Гораздо более узкой, чем сложилось
> исторически.
>
> >> >> А потом - ты valgrind на свои программы часто натравливаешь?
> >>
> >> ПК> Ни разу не натравливал. Хотя было несколько таких затыков, что я
> >> ПК> уже начал искать инструменты такого рода, и нашёл, в том числе и
> >> ПК> valgrind. Но воспользоваться ими не успел, во всех случаях на
> >> ПК> следующий день, отдохнувши поглядев, всё нашлось.
> >>
> >> А ты натрави. Имеешь шанс узнать что-нибудь интересное...
>
> ПК> Наверняка узнаю некоторое количество неучтённых мелочей. Крупные
> ПК> leaks видно сразу, а те того может и не стоят.
>
> Если только лики, и программа уровня hello world - то да, может, и не
> стоят...
>
> >> >> И на каждое выделение памяти. Вверх по всему стеку вызовов.
> >>
> >> ПК> Если не увлекаться вызовом malloc() inline, а каждый "объект"
> >> ПК> делать набор функций create, destroy и т.д. то это не много и
> >> ПК> оправдано. Кстати, разделяя функционал от интерфейса и выделив
> >> ПК> библиотеку, так даже проще.
> >>
> >> Любая попытка выделить память может закончиться неудачей. И называется
> >> она malloc() или create - рояля не играет. Ну, с точностью еще до
> >> классических грабель "объективизации" конструкции, описанных во всех
> >> книжках по C++ - "что будет, если ошибка произойдет в момент, когда
> >> память выделена под _часть_ подобъектов?"
>
> ПК> Если ты программист Си - решать тебе что будет.
>
> Не вопрос. Но существует только один приемлемый способ решения -
> аккуратно очистить все, что успело выделиться до этого момента. В
> случае с C - вручную отследив, что же успело выделиться.
Что значит успело выделиться? Само оно не выделяется, по крайней мере в
Си.
> Нет, тут тоже
> существует обходной маневр. Ценой определенной дисциплины организации
> функций, пары-тройки макросов для поддержки оной дисциплины и нескольких
> дополнительных строчек на каждое выделение.
Так и получается когда программист не знает "как оно работает". Тогда
да, и само выделяется, и выслеживать надо.
> ПК> Мне, например, не нравится как такие ситуации отработал
> ПК> spamassassin написанный на perl. Смотри тред "OOM-Killer". С
> ПК> perl'ом даже OOM-Killer не справился.
>
> А это - проблема, перпендикулярная. Если тебе в сишной программе
> понадобилась память - ты ее точно так же будешь запрашивать.
Один раз, потом верну ошибку назад по стеку, там пусть решают что
делать.
> >> >> >> ПК> Мне нравится с годами углубляться в один и тот же язык, чем
> >> >> >> ПК> с каждым годом изучать их больше. На Си можно сделать всё,
> >> >> >> ПК> а тебе видимо приходится слазить с Тикля иногда.
> >> >> >>
> >> >> >> ПК> Вопрос удобства можно обсудить, очень интересно.
> >> >> >>
> >> >> >> Это не мне, это Печникову "приходится слазить". А я под задачу
> >> >> >> подбираю наиболее удобный инструмент.
> >> >>
> >> >> ПК> Хорошо, что он у меня один. Кроме, когда на коленке надо, тогда
> >> >> ПК> shell. Perl, конечно, было бы круто знать, что иногда
> >> >> ПК> использовать вместо shell, но мне лень его изучать, я на Си не
> >> >> ПК> на много медленее напишу.
> >> >>
> >> >> Если писать на перле как на C, то да, на C ненамного медленнее
> >> >> получится. Вот только те, кто изучает не языки, а программирование,
> >> >> на перле пишут по-другому. Как на перле :-) И C сразу начинает
> >> >> отставать если не в сотни раз, то в десятки уж точно.
> >>
> >> ПК> В это мне тяжело въехать.
> >>
> >> Тяжело въехать в перловый способ программирования, тяжело понять любой
> >> способ программирования, отличный от однажды выученного, или тяжело
> >> поверить, что однажды выученный не является единственным?
>
> ПК> 1. Я не говорил, что на Perl ничего не писал, просто ничего серьёзного
> ПК> не писал. А в способ я въехал.
> ПК> 2. Способ программирования в основном от языка не зависит, и нет, не
> ПК> тяжело понимать новые, даже нравится, если видно где они эффективнее.
> ПК> 3. Я не в религиозном кружке чтобы просто так поверить в то или иное.
>
> ПК> У Perl'а своя ниша, и он хорош пока от туда не вылазит.
>
> Не вопрос. Она у него даже малость поуже, чем у C. Проблема в том, что
> C из своей ниши вылазит...
Посмотрим что успешно пишут на Си: драйвера, демоны, серверные,
клиентские, десктопные приложения, и т.д.
> >> Ты на sh тоже как на C пишешь? (Там, впрочем, если писать аккуратно,
> >> это бывает оправдано...)
>
> ПК> А это как?
>
> command
> if [[ $? == ... ]]; then
> ...
> fi
>
> И т.п. Это если "как писать". Если "когда оправдано" - вместо пайпов
> использовать временные файлы, потому что классический sh умеет вернуть
> код только последней команды в пайпе, успех завершения остальных
> проверить невозможно. В bash или zsh можно, но тоже очень
> небесплатно... (На самом деле сейчас придет Чеусов и скажет, что на
> классическом sh тоже можно - но ты попроси его тогда этот код показать,
> он у него, кажется, есть...)
Иногда приходится и так писать. Спорить не буду, на perl' было бы легче.
--
Покотиленко Костик <casper@meteor.dp.ua>
Reply to: