В Чтв, 19/03/2009 в 23:32 +0300, Artem Chuprina пишет: > Покотиленко Костик -> [email protected] @ Thu, 19 Mar 2009 > 20:44:07 +0200: > > >> Ну и там прочее по мелочи - "а что у нас не освободится, если вылетит > >> ошибка вот тут?" > >> > >> Разумеется, без gtk_widget_destroy() или там EVP_PKEY_free() было бы > >> совсем хреново. Но с ними - просто хреново, а не хорошо. Ну разве что > >> "слаще репы не едал"... > > ПК> У меня такое бывает редко, а когда бывает - заварю чаю и почитаю > ПК> кто кого освобождает а кто кого нет, сравню с кодом и всё готово, > ПК> делов-то 20 минут. > > Начнем с того, что ты вынужден тратить время и, главное, внимание, на > то, чтобы этих ошибок не допустить.
Это культура программирования, _этому_ учиться надо. > А потом - ты valgrind на свои программы часто натравливаешь? Ни разу не натравливал. Хотя было несколько таких затыков, что я уже начал искать инструменты такого рода, и нашёл, в том числе и valgrind. Но воспользоваться ими не успел, во всех случаях на следующий день, отдохнувши поглядев, всё нашлось. После какого-то такого случая, я написал простенький профайлер, обёртку для malloc и free с модулем статистики. Использую её в задачах, где сам не уверен где какие узкие места. Снимай статистику и хоть в rrd пиши. > >> >> Таким образом, у тебя в любом случае неудобный синтаксис и в любом > >> >> случае распределение памяти. Ты от них уйти не можешь. > >> > >> ПК> Чем вдруг? > >> > >> Синтаксис излишне многословен. Сокращать, конечно, можно, но помнить, > >> под каким сокращением у тебя что живет, все равно надо. На NULL на > >> каждый чих проверить тоже все равно надо (ну, при хорошем дизайне - > >> через один чих). > > ПК> Не через один, а один раз на каждый неподвластный вход. > > И на каждое выделение памяти. Вверх по всему стеку вызовов. Если не увлекаться вызовом malloc() inline, а каждый "объект" делать набор функций create, destroy и т.д. то это не много и оправдано. Кстати, разделяя функционал от интерфейса и выделив библиотеку, так даже проще. > ПК> А все подвластные входы не должны давать неожиданностей, этому > ПК> время уделять надо, оно окупается. > > "Не должны" не значит "не дают"... Впрочем, это уже мелочи. > > >> >> При языке высокого уровня же ты можешь вынести в отдельную > >> >> библиотеку то, что таки да, надо сделать на C (хинт: вообще-то > >> >> бОльшую часть работы с низким уровнем и на них можно сделать > >> >> достаточно эффективно - тот же бинарный протокол на tcl > >> >> реализовать в разы проще, чем на C). > >> > >> ПК> Мне нравится с годами углубляться в один и тот же язык, чем с > >> ПК> каждым годом изучать их больше. На Си можно сделать всё, а тебе > >> ПК> видимо приходится слазить с Тикля иногда. > >> > >> ПК> Вопрос удобства можно обсудить, очень интересно. > >> > >> Это не мне, это Печникову "приходится слазить". А я под задачу > >> подбираю наиболее удобный инструмент. > > ПК> Хорошо, что он у меня один. Кроме, когда на коленке надо, тогда > ПК> shell. Perl, конечно, было бы круто знать, что иногда использовать > ПК> вместо shell, но мне лень его изучать, я на Си не на много медленее > ПК> напишу. > > Если писать на перле как на C, то да, на C ненамного медленнее > получится. Вот только те, кто изучает не языки, а программирование, на > перле пишут по-другому. Как на перле :-) И C сразу начинает отставать > если не в сотни раз, то в десятки уж точно. В это мне тяжело въехать. -- Покотиленко Костик <[email protected]> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
