В Птн, 20/03/2009 в 16:32 +0300, Artem Chuprina пишет: > Покотиленко Костик -> [email protected] @ 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' было бы легче. -- Покотиленко Костик <[email protected]> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
