В Птн, 20/03/2009 в 00:56 +0300, Artem Chuprina пишет: > Покотиленко Костик -> [email protected] @ 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 пишешь? (Там, впрочем, если писать аккуратно, > это бывает оправдано...) А это как? -- Покотиленко Костик <[email protected]> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
