Re: Функционал и интерфейс
Покотиленко Костик -> debian-russian@lists.debian.org @ Thu, 19 Mar 2009 23:00:22 +0200:
>> >> Ну и там прочее по мелочи - "а что у нас не освободится, если вылетит
>> >> ошибка вот тут?"
>> >>
>> >> Разумеется, без gtk_widget_destroy() или там EVP_PKEY_free() было бы
>> >> совсем хреново. Но с ними - просто хреново, а не хорошо. Ну разве что
>> >> "слаще репы не едал"...
>>
>> ПК> У меня такое бывает редко, а когда бывает - заварю чаю и почитаю
>> ПК> кто кого освобождает а кто кого нет, сравню с кодом и всё готово,
>> ПК> делов-то 20 минут.
>>
>> Начнем с того, что ты вынужден тратить время и, главное, внимание, на
>> то, чтобы этих ошибок не допустить.
ПК> Это культура программирования, _этому_ учиться надо.
Это не культура программирования. Это культура обхода ограничений языка
C. В лучшем случае. Выполнение работы, которую машина может сделать
лучше, культурой программирования называть не следует.
>> А потом - ты valgrind на свои программы часто натравливаешь?
ПК> Ни разу не натравливал. Хотя было несколько таких затыков, что я
ПК> уже начал искать инструменты такого рода, и нашёл, в том числе и
ПК> valgrind. Но воспользоваться ими не успел, во всех случаях на
ПК> следующий день, отдохнувши поглядев, всё нашлось.
А ты натрави. Имеешь шанс узнать что-нибудь интересное...
>> И на каждое выделение памяти. Вверх по всему стеку вызовов.
ПК> Если не увлекаться вызовом malloc() inline, а каждый "объект"
ПК> делать набор функций create, destroy и т.д. то это не много и
ПК> оправдано. Кстати, разделяя функционал от интерфейса и выделив
ПК> библиотеку, так даже проще.
Любая попытка выделить память может закончиться неудачей. И называется
она malloc() или create - рояля не играет. Ну, с точностью еще до
классических грабель "объективизации" конструкции, описанных во всех
книжках по C++ - "что будет, если ошибка произойдет в момент, когда
память выделена под _часть_ подобъектов?"
>> >> ПК> Мне нравится с годами углубляться в один и тот же язык, чем
>> >> ПК> с каждым годом изучать их больше. На Си можно сделать всё,
>> >> ПК> а тебе видимо приходится слазить с Тикля иногда.
>> >>
>> >> ПК> Вопрос удобства можно обсудить, очень интересно.
>> >>
>> >> Это не мне, это Печникову "приходится слазить". А я под задачу
>> >> подбираю наиболее удобный инструмент.
>>
>> ПК> Хорошо, что он у меня один. Кроме, когда на коленке надо, тогда
>> ПК> shell. Perl, конечно, было бы круто знать, что иногда
>> ПК> использовать вместо shell, но мне лень его изучать, я на Си не
>> ПК> на много медленее напишу.
>>
>> Если писать на перле как на C, то да, на C ненамного медленнее
>> получится. Вот только те, кто изучает не языки, а программирование,
>> на перле пишут по-другому. Как на перле :-) И C сразу начинает
>> отставать если не в сотни раз, то в десятки уж точно.
ПК> В это мне тяжело въехать.
Тяжело въехать в перловый способ программирования, тяжело понять любой
способ программирования, отличный от однажды выученного, или тяжело
поверить, что однажды выученный не является единственным?
Ты на sh тоже как на C пишешь? (Там, впрочем, если писать аккуратно,
это бывает оправдано...)
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
If a `religion' is defined to be a system of ideas that contains
unprovable statements, then Godel taught us that mathematics is not
only a religion, it is the only religion that can prove itself to be
one.
-- John Barrow
Reply to: