Re: Функционал и интерфейс
В Чтв, 19/03/2009 в 23:32 +0300, Artem Chuprina пишет:
> Покотиленко Костик -> debian-russian@lists.debian.org @ 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 сразу начинает отставать
> если не в сотни раз, то в десятки уж точно.
В это мне тяжело въехать.
--
Покотиленко Костик <casper@meteor.dp.ua>
Reply to: