Re: Функционал и интерфейс
В Птн, 20/03/2009 в 00:56 +0300, Artem Chuprina пишет:
> Покотиленко Костик -> debian-russian@lists.debian.org @ Thu, 19 Mar 2009 23:00:22 +0200:
>
> >> >> Ну и там прочее по мелочи - "а что у нас не освободится, если вылетит
> >> >> ошибка вот тут?"
> >> >>
> >> >> Разумеется, без gtk_widget_destroy() или там EVP_PKEY_free() было бы
> >> >> совсем хреново. Но с ними - просто хреново, а не хорошо. Ну разве что
> >> >> "слаще репы не едал"...
> >>
> >> ПК> У меня такое бывает редко, а когда бывает - заварю чаю и почитаю
> >> ПК> кто кого освобождает а кто кого нет, сравню с кодом и всё готово,
> >> ПК> делов-то 20 минут.
> >>
> >> Начнем с того, что ты вынужден тратить время и, главное, внимание, на
> >> то, чтобы этих ошибок не допустить.
>
> ПК> Это культура программирования, _этому_ учиться надо.
>
> Это не культура программирования. Это культура обхода ограничений языка
> C. В лучшем случае. Выполнение работы, которую машина может сделать
> лучше, культурой программирования называть не следует.
Слушай, давай на примерах? А то как-то размыто. Я буду рад признать, что
Си неэффективен, если наглядно покажешь.
> >> А потом - ты valgrind на свои программы часто натравливаешь?
>
> ПК> Ни разу не натравливал. Хотя было несколько таких затыков, что я
> ПК> уже начал искать инструменты такого рода, и нашёл, в том числе и
> ПК> valgrind. Но воспользоваться ими не успел, во всех случаях на
> ПК> следующий день, отдохнувши поглядев, всё нашлось.
>
> А ты натрави. Имеешь шанс узнать что-нибудь интересное...
Наверняка узнаю некоторое количество неучтённых мелочей. Крупные leaks
видно сразу, а те того может и не стоят.
> >> И на каждое выделение памяти. Вверх по всему стеку вызовов.
>
> ПК> Если не увлекаться вызовом malloc() inline, а каждый "объект"
> ПК> делать набор функций create, destroy и т.д. то это не много и
> ПК> оправдано. Кстати, разделяя функционал от интерфейса и выделив
> ПК> библиотеку, так даже проще.
>
> Любая попытка выделить память может закончиться неудачей. И называется
> она malloc() или create - рояля не играет. Ну, с точностью еще до
> классических грабель "объективизации" конструкции, описанных во всех
> книжках по C++ - "что будет, если ошибка произойдет в момент, когда
> память выделена под _часть_ подобъектов?"
Если ты программист Си - решать тебе что будет. Мне, например, не
нравится как такие ситуации отработал spamassassin написанный на perl.
Смотри тред "OOM-Killer". С perl'ом даже OOM-Killer не справился.
> >> >> ПК> Мне нравится с годами углубляться в один и тот же язык, чем
> >> >> ПК> с каждым годом изучать их больше. На Си можно сделать всё,
> >> >> ПК> а тебе видимо приходится слазить с Тикля иногда.
> >> >>
> >> >> ПК> Вопрос удобства можно обсудить, очень интересно.
> >> >>
> >> >> Это не мне, это Печникову "приходится слазить". А я под задачу
> >> >> подбираю наиболее удобный инструмент.
> >>
> >> ПК> Хорошо, что он у меня один. Кроме, когда на коленке надо, тогда
> >> ПК> shell. Perl, конечно, было бы круто знать, что иногда
> >> ПК> использовать вместо shell, но мне лень его изучать, я на Си не
> >> ПК> на много медленее напишу.
> >>
> >> Если писать на перле как на C, то да, на C ненамного медленнее
> >> получится. Вот только те, кто изучает не языки, а программирование,
> >> на перле пишут по-другому. Как на перле :-) И C сразу начинает
> >> отставать если не в сотни раз, то в десятки уж точно.
>
> ПК> В это мне тяжело въехать.
>
> Тяжело въехать в перловый способ программирования, тяжело понять любой
> способ программирования, отличный от однажды выученного, или тяжело
> поверить, что однажды выученный не является единственным?
1. Я не говорил, что на Perl ничего не писал, просто ничего серьёзного
не писал. А в способ я въехал.
2. Способ программирования в основном от языка не зависит, и нет, не
тяжело понимать новые, даже нравится, если видно где они эффективнее.
3. Я не в религиозном кружке чтобы просто так поверить в то или иное.
У Perl'а своя ниша, и он хорош пока от туда не вылазит.
> Ты на sh тоже как на C пишешь? (Там, впрочем, если писать аккуратно,
> это бывает оправдано...)
А это как?
--
Покотиленко Костик <casper@meteor.dp.ua>
Reply to: