[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Функционал и интерфейс



В Срд, 18/03/2009 в 20:52 +0300, Artem Chuprina пишет:
> Покотиленко Костик -> debian-russian@lists.debian.org  @ Wed, 18 Mar 2009 17:08:20 +0200:
> 
>  >> Как только ты на C выбираешь достаточно высокий уровень, ты немедленно
>  >> получаешь высокоуровневый подъязык с неудобным синтаксисом и
>  >> ... правильно, все равно заботой о распределении памяти (почистить за
>  >> тобой все равно никто не сможет).
> 
>  ПК> В GTK+, создаёшь виджет "окно", напихиваешь туда кучу других
>  ПК> виджетов, потом делаешь gtk_widget_destroy() на "окно", и
>  ПК> освобождаешь его и всех потомков одной командой. Так что это дело
>  ПК> инструментов, а GTK+ и кстати glib это умеют.
> 
> Не, мужик, сделать gtk_widget_destroy() ты все равно вынужден вручную.
> Что накладывает довольно специфические требования на то, как пишется
> функция, дабы не забыть это сделать ни по какой ветки, не говоря уже о
> том, чтобы не сделать это ненароком дважды.

Про ненароком опустим...

> Ну и там прочее по мелочи - "а что у нас не освободится, если вылетит
> ошибка вот тут?"
> 
> Разумеется, без gtk_widget_destroy() или там EVP_PKEY_free() было бы
> совсем хреново.  Но с ними - просто хреново, а не хорошо.  Ну разве что
> "слаще репы не едал"...

У меня такое бывает редко, а когда бывает - заварю чаю и почитаю кто
кого освобождает а кто кого нет, сравню с кодом и всё готово, делов-то
20 минут.

>  >> Таким образом, у тебя в любом случае неудобный синтаксис и в любом
>  >> случае распределение памяти.  Ты от них уйти не можешь.
> 
>  ПК> Чем вдруг?
> 
> Синтаксис излишне многословен.  Сокращать, конечно, можно, но помнить,
> под каким сокращением у тебя что живет, все равно надо.  На NULL на
> каждый чих проверить тоже все равно надо (ну, при хорошем дизайне -
> через один чих).

Не через один, а один раз на каждый неподвластный вход. А все
подвластные входы не должны давать неожиданностей, этому время уделять
надо, оно окупается.

>  >> При языке высокого уровня же ты можешь вынести в отдельную библиотеку
>  >> то, что таки да, надо сделать на C (хинт: вообще-то бОльшую часть работы
>  >> с низким уровнем и на них можно сделать достаточно эффективно - тот же
>  >> бинарный протокол на tcl реализовать в разы проще, чем на C).
> 
>  ПК> Мне нравится с годами углубляться в один и тот же язык, чем с каждым
>  ПК> годом изучать их больше. На Си можно сделать всё, а тебе видимо
>  ПК> приходится слазить с Тикля иногда.
> 
>  ПК> Вопрос удобства можно обсудить, очень интересно.
> 
> Это не мне, это Печникову "приходится слазить".  А я под задачу подбираю
> наиболее удобный инструмент.

Хорошо, что он у меня один. Кроме, когда на коленке надо, тогда shell.
Perl, конечно, было бы круто знать, что иногда использовать вместо
shell, но мне лень его изучать, я на Си не на много медленее напишу.

-- 
Покотиленко Костик <casper@meteor.dp.ua>


Reply to: