![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
avvaWhy C Is Not My Favourite Programming Language — статья в Kuro5hin с длинной дискуссией в комментариях.
Статья довольно глупая, откровенная провокация на флейм. Тем не менее, в ней есть немало любопытных trivia, а в дискуссии встречаются, в стоге бреда, несколько интересных иголок.
Я не знал, кстати, что "you musn't cast the return value of malloc()". Это, конечно, тоже неправда, но проверка показала, что, действительно, завсегдатаи comp.lang.c советуют этого не делать. Вот здесь, например, подробно объясняется, почему: потому-что, во-первых, при правильном использовании malloc() это совершенно ничего не даёт (возвращаемый malloc() результат типа void* и так будет правильно приведён к нужному типу), а во-вторых, в случае, если вы забыли включить stdlib.h, то компилятор будет считать malloc() функцией, возвращающей int, но из-за эксплицитного приведения не выдаст ошибки и (на некоторых архитектурах) сгенерирует неправильный код.
Вряд ли я, впрочем, последую этому совету: привык приводить результат malloc(), а проверка того, что не забыл #include <stdlib.h>, у меня и так намертво в голове зашита.
Что же касается переносимости (так Лингво предлагает переводить portability) кода на C, то как раз позавчера произошло порадовавшее меня событие: Брэд взял написанный мной сервер memcached, и попробовал скомпилировать и запустить его на 64-битной машине (до сих пор никто этого не пробовал, включая меня). Заработало без всяких проблем с первого раза. Если учесть, что memcached только и делает, что очень интенсивно работает с памятью и сложными структурами кэширования информации, очень неплохой результат, по-моему.
Статья довольно глупая, откровенная провокация на флейм. Тем не менее, в ней есть немало любопытных trivia, а в дискуссии встречаются, в стоге бреда, несколько интересных иголок.
Я не знал, кстати, что "you musn't cast the return value of malloc()". Это, конечно, тоже неправда, но проверка показала, что, действительно, завсегдатаи comp.lang.c советуют этого не делать. Вот здесь, например, подробно объясняется, почему: потому-что, во-первых, при правильном использовании malloc() это совершенно ничего не даёт (возвращаемый malloc() результат типа void* и так будет правильно приведён к нужному типу), а во-вторых, в случае, если вы забыли включить stdlib.h, то компилятор будет считать malloc() функцией, возвращающей int, но из-за эксплицитного приведения не выдаст ошибки и (на некоторых архитектурах) сгенерирует неправильный код.
Вряд ли я, впрочем, последую этому совету: привык приводить результат malloc(), а проверка того, что не забыл #include <stdlib.h>, у меня и так намертво в голове зашита.
Что же касается переносимости (так Лингво предлагает переводить portability) кода на C, то как раз позавчера произошло порадовавшее меня событие: Брэд взял написанный мной сервер memcached, и попробовал скомпилировать и запустить его на 64-битной машине (до сих пор никто этого не пробовал, включая меня). Заработало без всяких проблем с первого раза. Если учесть, что memcached только и делает, что очень интенсивно работает с памятью и сложными структурами кэширования информации, очень неплохой результат, по-моему.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2004-02-10 09:07 am (UTC)Боюсь, что Ваш пример не показателен. Грамотно написанный код переносим в любом языке. Другое дело, что не все языки этому способствуют.
no subject
Date: 2004-02-10 09:11 am (UTC)захотелось ;-)
no subject
Date: 2004-02-10 09:29 am (UTC)ИМО любая программа, скомпилированная так, что компилятор разрешает недекларированные функции, работает по чистой случайности.
no subject
Date: 2004-02-10 09:30 am (UTC)что касается его недостатков, то это то что С библиотека стандартизирует лишь очень старые и морально устаревшие функции. поэтому для любого мало-мальски серьезного проекта приходится писать/реюзать свои собственные функции. Кстати одна из самых больших недостатков маллока ( для меня) это то что маллок() возвращает память non-aligned. Это приводит к достаточно серьезным проблемам
Re:
Date: 2004-02-10 09:53 am (UTC)Re:
Date: 2004-02-10 10:31 am (UTC)Re:
Date: 2004-02-10 10:44 am (UTC)no subject
Date: 2004-02-10 11:02 am (UTC)А проблема с aligment решается или простеньким wrapper макро для malloc, или использованием другого аллокатора. Это же не часть языка, а просто библиотечная функция.
Вообще alignment - уродливый performance hack и никакой специальной поддержки в general purpose programming language ИМХО не заслуживает.
Re:
Date: 2004-02-10 10:09 pm (UTC)no subject
Date: 2004-02-10 10:53 am (UTC)C делает как раз то, зачем его придумали, а именно нечто довольно low-level, но относительно портативное.
Лично мне кажется, самая большая проблема для портативности в C - неспецифицированная длина типов. Поэтому не мешает пользоваться библиотечными типами аля int16. Вот с поинтерами беда. В low-level языке нужен механизм точной декларации адресных типов. Тогда и кастать к ним можно было бы без зазрения совести, да и код бы получился компактнее на машинах, поддерживающих несколько режимов адресации.
Еще бесит макро синтакс для function pointers.
Подавляющее большинство проблем с buffer overflow можно избежать, если не пользоваться sscanf и типами unsigned :) Еще есть профайлеры/аллокаторы которые ловят доступы в неаллокированную память и есть StackGuard. Путаницу с между = и == легко избежать в случае констант, если приучиться всегда использовать константы как lval (типа 5 == x)
Остальные наезды просто не по существу. Проблемы, которые в общем-то все признают как таковые, даже и не упомянаются. (например слегка сломанная прецидентность операторов и путаница с return values аггрегатных типов (array/struct))
no subject
Date: 2004-02-11 01:02 am (UTC)http://www.cs.berkeley.edu/~fateman/papers/software.pdf
no subject
Date: 2004-02-11 01:05 am (UTC)Re:
Date: 2004-02-11 01:07 am (UTC)На С надо писать осторожно, мы пишем на С только расширения, а сам софт на Scheme
my 2c
Date: 2004-02-12 05:24 pm (UTC)Recently I saw a huge proprietary "component library" produced by a C++ celebrity ... Implementation of double-linked list is 1,500 lines long and an overhead per stored element is about 40 bytes. Oh yes, and of course it's a full template (every algorithm is T-parametrized).
Peaceful discussions with people, who say that C is bad because of its memory allocation or its tolerance of undeclared functions, will require someone like St.Francis of Assisi, because it's not unlike preaching to animals.
Re: my 2c
Date: 2004-02-15 07:01 am (UTC)А кем, если не секрет? Александреску?
Re: my 2c
Date: 2004-02-15 03:20 pm (UTC)no subject
Date: 2006-11-08 09:13 am (UTC)no subject
Date: 2006-11-08 12:51 pm (UTC)У каждого класса отдельно есть своя LRU queue всех записей в этом классе - каждый раз, когда кто-то просит прочесть какую-то запись, она перемещается в начало списка своего класса. Таким образом, в конце списка находятся те записи, которых давно никто не просил - их куски освобождаются, когда нужно место для новой записи в этом классе, и нельзя больше согласно конфигурации попросить памяти у системы.
no subject
Date: 2006-11-08 01:17 pm (UTC)