Re: Функционал и интерфейс
Покотиленко Костик -> 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 тоже можно - но ты попроси его тогда этот код показать,
он у него, кажется, есть...)
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
Феаноринги думают руками, арфинги - сердцем, а нолфинги - головой. (С)энта
Reply to: