Обсуждение:Pure C

Материал из Lurkmore

Перейти к: навигация, поиск

Содержание

"Мёртвый язык" и "голые" факты

Нынешний вариант раздела "Мёртвый язык" фактически не точен.

Утверждение "Сейчас, конечно же, это не так, и Си успешно вытеснили практически отовсюду" предлагается дополнить парадоксальным наблюдением ", при этом Си остается самым популярным (или вторым после Java) языком по всем мыслимым критериям и индексам. Раз, два, три."

Разумеется, не обходится без исключений, но здесь испольуется не композитный индекс и, если объединить C и C++, получим вторую позицию после вездесущей Java.

Обратите внимание, что тема популярности Си поднимается уже во второй раз за последние два года - см. рекомендованную ссылку из tiobe ниже по тексту в подразделе По поводу «Си мертв» за 2012. — 05:13, 19 марта 2014 (MSK)

Это просто такой троленк...

Статья хороша

Но все же добавьте информацию, где же и чем С лучше С++ недавних быдлопыхпыхкодер-кун, сейчас - сиплюсплюс-кун

Статья в ужасном состоянии. Аффтарские грамматика, пунктуация и способ изложения мыслей будят во мне угнетателя. Нет пути. --Arkanoid man 14:26, 18 декабря 2008 (MSK) ты хуй

А мне статья понравилась. Пунктуацию чуток подправить, но написано остроумно. Зачот чуть более чем полностью.

IRL, статья пидирастически хуёва, десу! -- Ононимус 16:48, 19 декабря 2008 (MSK)

Статья полное говно. Си - язык, на котором написаны ядра всех UNIX-подобных систем (в том числе linux, он самый). И блядь никакие свистопердящие C++ в код ядра не пускаются. Существуют проекты создания ОС в промежуточной среде, типа ява-машины и сраного .NET, но пока чего-то нихуя у них не вышло. Так, что если бы автор сего опуса писал нормальные системные, нужные проги, а не быдлопорграммульки на бейсике для офиса, то он бы знал, почему Си лучше С++, и уж тем более всяких Ява/С#. Если от программы требуется надежность и безотказность (например, если эта программа отвечает за ПРО, или за систему жизнеобеспечения, или блядь хотя бы за серверный процесс, который управляет всеми этими полезными феньками типа SQL), а не кавайные гуйки, то выигрывает Си. Да, и еще, хотя Си не единственный язык компиляторов, но все-таки в этой области он также рулит (компиляторы интерпретаторы, идиот, PHP, Perl, Java написаны на Си). И последнее, когда требуется высокопроизводительный код, то даже если прога написана на Perl (mod_Perl, например) после компиляции код транслируется все-таки в Си-код. Всегда ваш программист-многостаночник (Pascal, Delphi, С, С++, С#, Java, Perl и даже PHP, VB). Прошу школоту пройти на хуй. 

    >Автор - школьник еще тот. Пхп и перл - интерпретируемые языки, а не компилируемые.
    >Надёжность и безотказность ... Си
    лол

    > Если от программы требуется надежность и безотказность (например, если эта программа отвечает за ПРО, или за систему жизнеобеспечения
    то её пишут на Аде, а не на Си

Статья безграмотна

  • Раздел "Переполнение буфера", предпоследний абзац: в C# есть управление памятью и указатели. Нужно только в настройках компилятора разрешить использование небезопасного кода и блоки, в которых используются указатели пометить как unsafe.
  • «вменяемый exceptioning» был в 80-е в MIT, автору предлагается курить известную статью под названием «worse is better», в которой объясняется, почему технологии MIT не попали в мейнстрим.
  • в C++ exceptioning не является вменяемым, по той причине, что исключения в C++ не возобновляются, и по ряду других причин.
Да ладно-ка «не возобновляются». Оператор throw без аргумента does the thing MrBlack 14:11, 19 декабря 2008 (MSK)
Это не то. Он прокидывает исключение дальше, а «возобновить» — значит продолжить выполнение с любого места в раскрученном стеке вызовов. Первая ссылка в гугле по запросу «lisp exceptions». Хотя pure C тут уже ни при чём.
  • BSOD тут вообще ни при чём.
  • на C можно писать вполне ОО-программы, автору предлагается курить исходники ядра Линуха и GTK.
Ну, если использование неких соглашений вместо ОО-синтаксиса можно назвать ООП, то и на асме это вполне можно делать MrBlack 14:11, 19 декабря 2008 (MSK)
О том и речь, что можно делать, но не очень удобно. И на C++ ОО-программы писать неудобно тоже.
Всё зависит от кривизны рук и места их произрастания. А то, что на C++ (который, да, совместим с С, но тем не менее вполне себе ОО-язык) неудобно писать ОО программы — сильно сказано.
ну, если использование неких соглашений в синтаксе вы считаете ООП... алсо, вот пример из windows-мира - цикл из 8 статей об использовании COM на чистом C: http://www.codeproject.com/KB/COM/com_in_c1.aspx

--Arkanoid man 14:26, 18 декабря 2008 (MSK)автор курит исходники ядра и многие другие и без сопливых

  • на что как бы намекает автор, говоря о типах файлов в /usr/bin и /usr/sbin ?
  • код на С защищён по полной, кроме ручного управления памятью (и соответственно её утечкой и др. негативными проявлениями, о которых, кстати, нет ни слова).
  • полное не понимание, что такое скрипты и зачем они нужны. (Ядро на Perl! ОЯЕБУ!)
  • Не рассказано, что C++ не смог заменить С потому что его не способен до конца понять даже сам аффтар (было такая фраза, я гарантирую это). Да и эта ваша ОО нужна только в 3 типах задач (один из которых GUI). Поэтому в Юниксах С и живее всех живых.
  • Objective-C — это предок, а не потомок С++.
Вообще не потомок и не предок. Он появился раньше, да, но Страуструп не с ObjC разрабатывал плюсы. И да, под айфоне можно писать софт ТОЛЬКО на нем, даже жаба в пролете. Однако, можно линковать сишные библиотеки.

Любопытно, кроме C++ у Си есть ещё один обратно-совместимый родственник

Нихуя С++ не обратно совместим. Попробуй скомпилить сишную прогу где переменная называется new с помощью С++ компилятора.

  • С нихуя не быстрее того же Fortran’а (и любого компилируемого языка). Ну, может на сферическиий 1%. Просто он как связующий слой — самый тонкий.
Фортрана и асма то да. А вот приплючнутого и тем более явы и уж совсем тем более python'a, если автор не тупой криворукий школьник — как то и сравнивать глупо.
  • Не освящена ситуация с более чем 9000 вариантам того же «чистого» С.
  • Примеры употребления указателей — неуместны и не по делу. Таким образом их их употребляют только быдлокодеры, кем, похоже, и является автор статьи.
  • На языке C пишут множество драйверов, утилит, демонов и библиотек. Огромное количество разработок происходит внутри компаний и закрыто от посторонних глаз. Занимаются этим далеко не только бородатые олдфаги, а люди самых разных возрастов.

Запилите статью и не позорьтесь!

Какое mime? Какое ООП?

В статье спутано все. Алсо, расовый ОП (не быдляческий ОО, а именно О) — это смоллток и детки. А то, что наизобретал Страус и всякие коммитеты — плюсы, жабка и прочий сишарп — уже ООП, которое убило все идеи ОП и выебало труп в жопу.

--Arkanoid man 14:26, 18 декабря 2008 (MSK) Про то и речь, читай сноску в разделе ООП данной статьи. Хочешь рассказать так, чтобы было понятно что сигнальная модель рулит - велкам.

Алсо, причем тут mime к файлам в /usr/bin?

--Arkanoid man 14:26, 18 декабря 2008 (MSK) при том, что благодаря быдлоскриптам там теперь не только бинарники но и скрипты. Тысячи их!

Алсо 

$ file /usr/bin/* | grep -i i386 | wc -l
     648
$ file /usr/bin/* | grep -i script | wc -l
     292
$ uname -a
Darwin localhost 9.5.0 Darwin Kernel Version 9.5.0: [snip!]

Да, фагготерия!

Блять, трое уже сказали, что заголовки скриптов - это не MIME. clash-bang на сленге, но никак не mime.

Про ОП: забавно, но педивикия щитаит так: w:ОП ))

Look at diz: http://en.wikipedia.org/wiki/Smalltalk#Object-oriented_programming

Алсо Ето ваше ебучее ООП в хуй не упиралось для реального времени и ембеддед аппликацион, ибо ни одна песда на свете не скажет точно, какие танцы с бубнами устроит компилятор при вызове всяких конструкторов, а уж какими кирпичами ети ебаные конструкторы насрут в стек (ни разу не резиновый, алсо).

аффтар выдумал все сам?

Откуда он это взял? Си++ в середине 80-ых уже имел и компилятор, и драфт стандарта. ОП появился после 1981 года? Да не гони, Simula67, как это ни странно, появилась в 67-ом году. Про «выстрелить в ногу» — ты опредились, ты про Си рассказываешь, или про Си++ ? В Си достаточно указателя, void-функций там нет. В Си++ тоже хватает указателя, try-catch конструкции есть. А зачем надо «по смещению наложить структуру, пройтись по её полям» — вообще загадка.

>>Поэтому ядра и драйвера в их пространстве пишутся только на Си, и ни одного на Perl’е.
Драйвера вобще надо на PHP писать, у него тоже компилятор есть.

Статью писал нуб (пруфлинк?). Ограничиваюсь выставлением плашек, дабы не ввязаться в войну правок (уже идёт) (надо удалить примерно две трети текста). Потрудитесь изучить материал, и написать нормальную статью.

удалил ересь про /usr/sbin

Автору: /usr/sbin -- это не "исполняемые скриптовые файлы", а (как сообщает нам педивикия [[1]]) дополнительные системные программы, такие как демоны различных сетевых сервисов. Скриптовых файлов там чуть более, чем половина, но отнюдь не все.

С

Это нормальная статья. "С" создавался как замена ассемблеру именно для системного программирования. Спорить тут о том, что с ним пыталась сделать Microsoft, или кто-то другой, не надо - C++ и его разные названия пусть будут в отдельной статье. "С" сейчас - это язык для ВСЕХ встраиваемых компьютеров и микроконтроллеров. Если вы знаете об ARM или Atmel, вы знаете, что для них фирмы-разработчики выпускают компилятор для "С", чтобы "бородачи" не ебались со специфичным ассемблером. Суть "pure C" - именно кросплатформенное программирование, причём кросс - это не только Windows и *nix.

Внезапно двачую. Няшную сишку нужно перенести в категорию "ассемблеры", каковым она и является.
А ещё под Atmel есть среды под Basic и Pascal.
Годов так 80сятых.

Быдло детектед

Кто тут пиздит на рекурсию и указатели на ф-ции? Это же наше все и ф-ции высшего порядка соответственно. Читай SICP до просветления, быдлокодер! 

Из-за таких идиотов лисперов считают неалекватами. Если бы ты сам прочитал сикп внимательно, то знал бы что хвостовая рекурсия лиспа это итеративный процесс. Итеративный же процесс в си быстрее и менее прожорливей хвостовой рекурсии лиспа, читается( как и программируется) примерно также как и в лиспе(а для 99% программистов лучше). Рекурсивных процессов же следует избегать как в си, так и в лиспе. Есть конечно задачи которые решаются только рекурсией, но на практике в 90% случаев они выходят за область использования си. Первая глава сикпа, если мне не изменяет память.

прошу запилить ссылку на сайт эзотерических исходников

http://www.ioccc.org/

Быдло детектед-2

Для поиска memory leaks всю дорогу была куча инструментов. Тот же Ice или потом Purify. А местные быдлокодеры пишут чтой-то про статический анализ кода.

А где сравнение с великолепным D? Что за быдлячество!

C... такой С

Предлагаю добавить следующий код. 

#include <iostream>
using namespace std;
int main()
{
   int* g= new int[4];
   g[0] = 1;
   g[1] = 2;
   g[2] = 3;
   g[3] = 4;  
   g[--g[0]] = --g[g[0]++];
   for(int i=0;i<4;i++)
   {
      cout<<g[i]<<endl;
   }
   return 0;
}

"Код который ничего не решает".

Разве это не неопределенное поведение?
В новых версиях gcc решает. К тому же, эту херню и человек-то с трудом осиливает с первого взгляда. И эта... тут код на Плюсах.

Дофига плюсовых возможностей в коде просто усраться дофига

Ошибка в примечаниях

Уберите стыд из примечаний: "Острова" связанных объектов не вызывают утечек памяти в жаве уже очень давно (если и вызывали, в чем я сомневаюсь). Объекты собираются если на них нет ссылок из стека работающих потоков.

Проблема "островов" в Жабе была. А в примечании говорится не столько о дефектах твоей ненаглядной Жабы, сколько о дефективности некоторых погромистов, которые создают значительные по объёму сложносвязанные структуры и тягают их за собой во всё время исполнения программы, в виде элементов какого-нибудь списка, например, но никак их уже не используют.

Как же, блять, на нём пишут?

А очень просто. Хороший, годный bullet-proof код на Си в большой компании состоит из assert’ов чуть менее, чем на треть (на некоторых участках и вовсе наполовину). Проверяется вообще всё, что можно проверить. Аргументы на вход функций, результаты всех«» вызовов (и своих, и особенно тщательно и густо — внешних), каждый пук на каждой итерации хитрожопых алгоритмов. Память выделяется только самописными функциями-аллокаторами, а выделенным участкам с помощью макроса присваиваются метки вида «файл, номер строки» (чтобы ловить, откуда именно утекло), и параллельно куда-нибудь наружу неким thread-safe образом пишутся логи хода выполнения программы. Код выходит адски-тормозным (примерно как эти ваши C#/Java), и невъебенно-раздутым, но зато подавляющее большинство багов ловится легко, безболезненно и совсем недалеко от места их возникновения. Никакой порчи памяти, никаких утечек. В чём профит от адски-тормозного кода?

  1. После долгого и вдумчивого тестирования (и руками, и unit-test’ами) собирается release-билд, в котором все ассерты и логи отключены.
  2. Внезапно начинает работать inline всяких функций вида «5 ассертов и один вызов», эффективно убивая весь лишний abstraction penalty (ассертов-то больше нет).
  3. Выверты с выделением памяти прекращаются, никаких лишних меток и прочего клаттера.
  4. На выходе получается ультра-супер-быстрый и тщательно отлаженный бинарник.
  5.  ???????
  6. PROFIT

Кто-то скажет, что это пиздец. Но если стоит цель писать по-настоящему надёжный код, в любом другом языке придётся заниматься приблизительно тем же самым. Ассертить, ассертить и ещё раз ассертить. Каждый аргумент, каждый вызов. И волшебство «Моя любимая ява/C# в 5 раз более лаконична, чем ваш чистый C» рассеивается вмиг. Ну да, Си остаётся толще. Процентов на 5. При 10-20-кратном выигрыше в рантайме, если грамотно использовать SSE и помнить по кэш-миссы.

Реквестирую запил раздела в статью.

Ты ещё забыл про такую ненавистную индусам, быдлокодерам и школоте вещь, как графы состояний. Тупо на бумажке. Грубые, прикидочные исчирканные матом блок-схемы алгоритмов и структуры данных, которые позволяют ничего не проебать. Код, написанный на Цэ с предварительным составлением плана в голове (если она есть) обладает совершенно труднопостижимой надёжностью. У меня по служебной лавочке есть софтина из сорока взаимосвязанных плагинов, гоняющая жёсткий матан, которая ни разу не падала. То есть ВООБЩЕ ни разу. И когда я пишу сорок первый — в половине случаев после набора текста он собирается и работает, как надо, а во второй половине — сначала нужно найти и прибить мелкую опечатку. Я уже охамел до того, что при любой ошибке ищу её сразу в смежном ПО (ИЧСХ там и нахожу) — привык, что у меня в моём коде ошибок просто НЕТ. Да, и графический интерфейс там стоит по эффектности пары демосцен — и тоже весь через указатели за два вечера написан. Если ты умеешь пользоваться бумагой и карандашом, весь так называемый "прогресс" в области языков и сред разработки за последние 20 лет тебе не нужен.
Родной, вы видимо просто не писали относительно сложных приложений на С в группе (вариант - модификация уже написанных приложений). Никакие «графы состояний на бумажке» от неявных ошибок (ваших и чужих) вас не охранят. И время на отладку тратить придётся. И охаянный вами «прогресс языков за последние двадцать лет» покажется очень даже полезным.
Дражайший, верно подмечено, про неявные ошибки. Только вод беда - Си язык простой, неявную ошибку в нем допустить усраться надо (если опыт программирования есть и понимание как это работает), а вот в приплюснутом ошибку допустить проще простого - поди догадайся + у этой переменной thread-safe || fail, так чисто для справки. Чем сложней язык тем больше вероятность допустить "неявную ошибку". Спорить будем?
Ну давайте попробуем, ваше святейшество. В простом С допустить неявную ошибку - не усраться, а как два пальца обоссать. В приплюснутом - ещё проще, это верно. Любой "уехавший" указатель, неверный cast, забытый free, или просто другая версия компилятора - и вуаля. Если над проектом работают несколько разработчиков, то "нюансы" в коде одних часто производят глюки в коде других (как бы вы не старались согласовать стандарты). Причём при начальном тестировании эти ошибки вполне могут и не проявляться. А вот в Жабах и Си-шарпах (надеюсь, под "прогрессом языков за последние двадцать лет" вы всё-таки понимали их, а не ржавого монстра C++) эти ситуации встречаются значительно реже. Да, искоренить их совсем, наверное, невозможно, но приблизиться к идеалу продуктам "прогресса за двадцать лет", со скрипом и низкой производительностью, но удаётся. Так что не надо тут ля-ля :)
-> Немного поправлю последнего оратора: при строгом соблюдений всех правил структурного программирования, сознательного оказа от наворотов "весь алгоритм в одну строку", и самописном менеджере памяти ( с самписным же сборщиком мусора) даже без ассертов в сяшном коде ошибиться сложно. Я писал и много и в комманде под разные микропроцы (т.е. коду без разницы восмидесятка/ARM). В плане простоты написание единого (не разнесённого, как например, web) продакшн-приложения приложения С сравнится вразве только java. Только вот век тких приложений потихонечку уходит ...

Снимите млять редирект с шарпа

Быдлокодерам: Шарп не Ъ.--83.149.3.14 00:23, 10 ноября 2010 (MSK)

Увы, с точки зрения медиавики C и C# - одно и то же.

могло бы исключить появление BSOD

Кое-кто ехидно предполагает, что наличие хоть какого-нибудь вменяемого exceptioning’а в Си могло бы исключить появление BSOD в 90-х.

ЩИТО? Это бред, его нужно убрать. Сипыпышная фишка (лулз, конечно) с «exceptioning’ом» void foo(int *p, int c) { 

   try
      {
         *p=c;
      }
   catch (...)
      {
         printf("Щито?\n");
      }

}

не прокатывает в ядрах операционок. Ибо в ядре:

а) ядро распоряжается ресурсами. Хочет, запишет по адресу 0x80050000; перехочет- не запишет. Кто сказал, что это будет ошибка? Это может будет логическая ошибка, так как записывать в тот адрес ничего не нужно. Но никто, даже процессор не может определить является ли это ошибкой, или нет. Другое дело прога. Она не имеет права записывать куда хочет, а если попробует, то ось не позволит. А самой оси кто может запрещать?

б) код с try и catch раскручивается в ряд ассемблерных инструкций, которые пишут в разные области памяти (зависит от оси). При исключении ось сама передаёт управление из try в catch. В ядре очевидно это сделать некому.

в) Даже если попытаться придумать обработку исключений, то придётся учить матан. В ядре исключения управляются обработчиками исключений. Допустим, в ядре код что-то поделил на ноль. После такой инструкции проц генерирует исключение, ищет сопоставляет через таблицу векторов прерываний типу ошибке обработчик и передаёт управление ему. Чтобы как то «симулировать» придётся заставить компилятор при обработке блоков try catch записывать в таблицу векторов обработчик. А это гемморно, так как машинно-зависимо. Ассемблер, короче.

Так что не надо быдлокодить и писать такую ересь. —83.149.3.5 21:02, 17 ноября 2010 (MSK)


Надо же. Такая толстота, а работает.

вы ребята, не компелировали ни строчки рабочего кода в ring0, я гарантирую это. а хотите вступить? а что у вас есть?

быдлокодеры такие быдлокодеры. выучили заумные слова вроде GC и exception, и думают, что теперь могут писать Объектно-Ориентированное Ядро. интересно, а видел ли хоть один из них, на каком языке пишется обвязка к ихним супер-пупер-языкам? та самая, которая стек откручивает?

Для полный дебилов, которые вообще не в курсе, что такое BSOD и как срабатывают исключения (ага эти самые try), поясняю: 1. Кто драйверы не писал, заткнитесь: __try __except __finally - в ядре есть (ага, поверх чистого си) 2. В ваш except на великом и могучем языке программирования С++/Java/C#/Python/PHP/ещё-какая-ересь половина исключений отдаеться системой (опачки!) что как бы намекает, что выдаються вашиму сепер-объектному коду они из си на котором они отлавливаюсть 3. Полная херная вообще - BSOD выдаеться когда нет возможности правильно обработать возникшее исключение (!! их же тут нету, по мнению некоторых школьников) и система мечтает хоть на жеском диске что то вам на память оставить. А не форматнуть и его за компанию.

Пополните

Добавьте еще, что СИ - рабство в Древнем Китае. Немного википедности тут не помешает http://ru.wikipedia.org/wiki/Си_(Рабство) Тем более, язык неплохо ассоциируется с анальным рабством, что доставляет.

Идея для эпиграфа

«Си — инструмент, острый, как бритва: с его помощью можно создать и элегантную программу, и кровавое месиво». Керниган


Мне больше другое понравилось:

C хорошо подходит для двух вещей: для красоты и для создания катастрофических 0-day уязвимостей в операциях с памятью.

Название

«

Еще одну интерпретацию названия C++ можно найти в приложении к Оруэллу

»
— "Исторические замечания" в книжке Страуструпа

Читавшие Оруэла поймут

О быдлокодерах

Быдлокодеры на Си таки пишут, не надо. Грызут кактус но пишут. Правда большинство быдлокодеров уже давно свалило на C# но это не заслуга Си (как и не заслуга Си более ранний исход быдлокодеров на кресты). Быдлокодеры вообще на любом языке писать способны, даже на Perl, не говоря уже о таком простеньком но рутинном языке как Си. Рутина быдлокодерам кстати нравится, см. китайское наследование методом copy&paste


Запилите если охота

[URL=http://fastpic.ru/view/31/2011/1025/3b69de5be54b1017c5997af81947fd65.png.html][IMG]http://i31.fastpic.ru/thumb/2011/1025/65/3b69de5be54b1017c5997af81947fd65.jpeg[/IMG][/URL]

Блджат RMS основал GNU в 83-ем году

Относительно УГ после 81-го года. Копипаста с педивикии w:Linux:

GNU
Проект GNU был начат в 1983 году Ричардом Столлманом с целью создания «целостной Unix-совместимой программной системы», полностью состоящей из свободного программного обеспечения. Работа началась в 1984. Позднее, в 1985, Столлман основал Free Software Foundation, а в 1989 году составил GNU General Public License (GNU GPL). В начале 1990-х многие из программ, необходимых в операционной системе (такие, как библиотеки, компиляторы, текстовые редакторы, командная оболочка UNIX, и оконная система), были завершены, в то время как разработка низкоуровневых элементов, таких как драйверы, демоны и ядра была приостановлена и они оставались незавершёнными. Линус Торвальдс сказал, что если бы ядро GNU было доступно в то время (1991), он бы не решился написать своё собственное.

Ебаный стыд, "двойной указатель на функцию"

int (**f)(char *с) — двойной указатель на функцию, принимающую строку и возвращающую целое число

читается как:

указатель на указатель на функцию, алсо используется для массивов функторов w:Функтор_(программирование), например в этих ваших COM объектах, нечто подобное под названием vtbl (виртуальная таблица функций)

Технические решения, совершенно несопровождаемые в дальнейшем...

ЛПП, взять хотя бы этот же апач и кучу другого опенсурса, чуть более чем полностью написанного на С. А матан с указателями на функции запросто дефайнится, для уменьшения баттхерта быдлокодеров и улучшения читаемости кода вообще.

Алсо, тема с макроопределениями не раскрыта, а она собственно зачастую и является очень сильным колдунством, чуть менее чем всех программ выше студенческого курса, и иногда вызывающим лютый баттхерт даже у видавших виды гиков.

Как пример подойдёт?: void quest (int *a, int n) { n-- > 1 ? quest(a, n), quest(a+1, n), n=*a, *a=a[1], a[*a > n] = n : 0; }

declare foo as array of array...

Немного боян, но мне кажется, что эта картинка должна быть в статье.

По поводу «Си мертв»

Стоит, наверное, добавить ссылку на рейтинг Tiobe? Первое место с мая 2012 года. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

скобка перед точкой

Кто-нибудь, добавьте пожалуйста скобку после "(в том числе и интерфейс к iPhone"

facepalm

>Для начала можно упомянуть тот факт, что в C (и во всех производных языках) 1/3 будет равно 0. То есть выражение 1/3==0 истинно, а вот 1/3.0==0 — нет.
Автор этой строки, видимо, страдает слабоумием, и не понимает, что компилятор любого языка не умеет читать мысли и заранее знать формат частного двух int'ов. И, да, float-литералы пишуться с постфиксом f.

Глаголы не в инфинитиве «пишуться» без мягкого знака. В нормальных языках целочисленное деление делается отдельной операцией, потому что оно логически отличается от обычного, блеать.
Автор этой строки нихуя, наверное, не знает про типы. Тип обоих чисел - int, значит, и результат будет int.
Автор предыдущего высера наверное не знает, что в нормальных языках есть отдельно оператор деления a / b, а отдельно - целочисленного деления - a div b. Ну или a // b. Ути пути, расширяем кругозор, детишки!
Список "нормальных" языков в студию!
Python, Perl, Pascal, Lisp и все его производные, Smalltalk, да практически все, что выросло не из C/BCPL, окромя фортрана, и, внезапно, JavaScript: alert(1/3);
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 1 / 3
0
>>> 1 / 3 == 0
True
>>> 1 / 3.0 == 0
False

оператор --> операция

Вот в этой фразе: «При этом == как оператор равенства и знак равенства как оператор присваивания»

Благодать

благодатно братия, зело благодатно неплохо было-бы ещё описать ситуацию с ISO стандартами и разницу православного gcc с б-го ненавистой продукцией мелкомягких

Напиши, а лучше возьми задачку с интенсивными вычислениями и обращениями к памяти, да сравни время выполнения.

Оператор АДЫН-АДЫН

Запилите обязательно про двойное отрицание (aka оператор «адын-адын»), то есть про совершенно алогичный факт из логики C, а именно что: «a != !!a». Между прочим сей алогизм достаточно широко используется кошерными C-программистами для приведения произвольного значения к булевскому (то есть ко множеству {0, 1}). Например в коде linux попадается регулярно. Неподготовленному выносит мозг на первых порах. Например, сферично и в вакууме: 

/usr/src/linux/kernel/power/suspend.c:40:
 
static bool need_suspend_ops(suspend_state_t state)
{
	return !!(state > PM_SUSPEND_FREEZE)
}
Абсолютно логичный факт. Падаван, ты путаешь логику оператора «!» и логику оператора «~», учи матчасть.
Выискался тут, знаток языков. Я ничего не путаю, это ты пытаешься выглядеть умнее, чем ты есть на самом деле. Читай внимательно. Как ты понимаешь слова «алогичный факт»? Это ведь факт, который не вписывается в логику, так? Так. «!» позиционируется как логическое отрицание. Но в логике a == !!a, это легко доказывается из определения «!». То есть факт a != !!a является алогичным, то есть не фактом матлогики, а артефактом языка C. И когда в следующий раз будешь ставить мой интеллект под сомнение, подумай как следует, причём исходя из предположения, что ты наблюдаешь проблемы не с моим, а с твоим интеллектом, который не позволяет тебе видеть всю глубину моей блестящей мысли. — Срикет
Полегче, буквоед. Сперва научись свои блестящие мысли правильно озвучивать — очевидно же, что в таком случае следовало писать не «алогичный факт», а «факт, противоречащий математической логике». Это во-первых.
Во-вторых, точно так же очевидно, что операция отрицания в данном случае является булевой, как и ее результат. Закон двойного отрицания подразумевает, что в другой части твоего условия находится такой же логический элемент, но у тебя там стоит число/указатель/что угодно. Другими словами, ты сперва жопу с пальцем сравниваешь, а потом прибегаешь сюда хвастаться вчера прочитанными лекциями по дискретке.
Покажу на примере, чтобы было понятнее:
>>> (a) == (not (not a))
False
>>> bool(a) == (not (not a))
True
Ферштейн? Чтобы соблюдались законы математической логики, нужно и оперировать объектами этой самой логики.
Мудак ты, короче.
А вот Шарп, например, не даст сравнить крокодилов с бегемотами и на if (0 == false) {} выдаст ошибку конпеляции. — Мимо крокодил
Ну так можно долго примерами перебрасываться.
irb(main):002:0> a == !!a
=> false
В принципе я согласен с логикой Шарпа — строгая типизация и отсутствие неявных преобразований в данном случае избавляют от лишних вопросов со стороны блестящих мудозвонов людей с блестящими мыслями в голове.
UPD: cправедливости ради, нужно отметить, что пример выше не является корректным. В Ruby свое понимание происходящего:
irb(main):004:0> !(false)
=> true
irb(main):005:0> !(0)
=> false
> Чтобы соблюдались законы математической логики, нужно и оперировать объектами этой самой логики.
Лол… Да НЕУЖЕЛИ? ЧЁ СЕРЬЁЗНО?
Вот ведь, говорила мне мама, что объяснять идиотам бесполезно. А я не верю каждый раз, и каждый раз объясняю, в надежде, что идиот не настолько уж и идиот и в состоянии понимать. В общем, я постараюсь быть ещё более лаконичным и ещё более понятным: обосрался? Обтекай. Если ты обосрался так жидко, что тебе можно утереть нос вчера прочитанными лекциями по дискретке, то… Я даже затрудняюсь дать какой-нибудь совет. Может быть тебе лучше продолжить проходить ускоренный курс детского сада, в надежде когда-нибудь стать хотя бы школотой? — Срикет
Если тебе нечего ответить по существу, можно было бы ограничиться и простым «ты хуй». Слив засчитан, разговор окончен.
Всё отвечено выше, я не попугай повторять по десять раз одно и то же. Читать учись. Ты хуй. — Срикет

Ну можно почитать посмеяться

Конечно то что на Луркморе пишут, всерьез особо нельзя воспринимать.

Ну вообще говорят, якобы C# наоборот проще других языков для обучения.

Ну фиг знает, я начал изучать C# несколько месяцев назад. Сначала думал, что я вообще идиот, но вот спустя несколько месяцев уже разобрался немного в синтаксисе, и вообще в основах программирования, и пишу кое-как сам код, хотя конечно с подсказками иногда. )) Ха-ха, конечно мне далеко до профессионального программиста, задачи, на решение которых уходят дни, хороший программист напишет за минут 5-10, и более хорошо наверное)). Но в целом, с нуля я думаю вполне возможно изучать этот язык, если конечно проявлять определенный интерес в изучении языка. Ну я пишу программу несколько по-сложнее, чем "скриншотер" какой-то)), как тут про "быдлопрограммеров" пишут, и процентов 90-95 кода набирается на клавиатуре (ну кроме того, что "невидимо" автоматически пишется в программе по умолчанию")), а не "кликанием мышкой", хотя думаю конечно код кривой у меня)) но работает))

Хм, вообще программирование для общего развития мозга весьма полезная вещь, можно сказать куча "шарад", и решение "загадок". Поэтому для развития мозга вообще рекомендуется такое изучать всем, по моему мнению)) Чтобы не глупеть)). Ну знание математики нужно на уровне поставленных задач, у меня например только действия сложения, вычитания, умножения, деления, абсолютной суммы и логарифмы. ну там по формулам вычисление. А вот если там для программирования игр, три д и так далее, конечно нужен более высокий уровень математики.

Ну в школе упустил, программирование не было обязательным для изучения, как и информатика))

Когда я пишу на Фортране

Когда я пишу на Фортране, Господь подымает меня над полом и приближает к себе. Не так близко, чтоб поздороваться, но так высоко над вами, чтобы узнать вам, дешёвкам, цену. Вы писькины плевки, получившие паспорта, вы спрессованный в толпу корм для рыбок, ваши лица сливаются в одну огромную жопу. Человек без распечатки в портфеле есть такая низкая тварь, что даже утопая в реке, я не подам ему руку.

Самая короткая программа на С

Может кому будет интересно: main; самая короткая программа на С, которая компилируется без ошибок. Ну а во время выполнения -SIGSEGV подробнее http://habrahabr.ru/post/181021/ ЗАпилите в раздел ЭЗОТЕРИКА.

Уровень языка

"Является на сегодняшний день фактически самым низкоуровневым из языков высокого уровня" - Си-- и Форт не вполне понимают, что хотел сказать автор

картику добавьте

http://habrastorage.org/storage/habraeffect/7e/c6/7ec6526b2a6fa85a30736912c357c5b3.jpg

>писавшего когда-то в патлатой молодости на Java

Уберите этот бред. Уберите людей, которые цитируют это IRL. Сравнили осла с медведем.

  • Манагеры почти все такие. Особенно бывшие мусара, которых ставят руководить. Звёздочки и стрелочки ввергают их в ступор (как и написано в статье), затем вся группа разгоняется, проект начинают переписывать на C# или Java, но не успевают. Старо как мир, ещё анекдот был —
Однажды император Николай I, встретившись с Гречем на улице, спросил его:
— Скажите, пожалуйста, Греч: к чему служит в русской азбуке буква «ять»?
— Она служит, Ваше Величество, как знак отличия грамотных от неграмотных, — ответил Греч не задумавшись.
Так-то.

Статья - высер неудачника, не осилившего Си

Автор, кроме visual basic в школе, небось больше ничего не изучал. переполнение буфера (как уязвимость) происходит по причине рукожопия программиста (в 80% случаев, по вине программистов мелкософта. А открытая форма доступа к памяти - скорее специфика языка, и не надо на это напирать!), а в текстбоксах на формах можно ограничивать длину строки + WinAPI взятия текста из формы имеют в аргументах фиксированную максимальную длину. Так что с вводом длинны капчи через форму могут зафейлиться только полные наркоманы. Также нормальные люди в стек никогда огромные массивы (строк, чисел) не кладут (стек не резиновый), а выделяют под это дело отдельно динамическую память, где перезапись за границу памяти может вызвать только исключение. Разница в длинах чаще всего неочевидна и попадается при тщательных "раскопках" в глубине кода. И далеко не всегда это строки, если в самой винде, то могут быть структуры данных. Учись писать шеллкод, сука!— Мимо проходил взломщик-кун

Эзотерика

Есть еще такая простенькая эзотерика: например, делимость нацело (кратность e.g.) целого A на 2^n, можно проверять, как !(A & (2^n - 1)). Битовым операциям в статье вообще не уделено почти никакого внимания, а с этим как раз связана львиная доля всякой эзотерики в С.

  • Байтоёбство — это как православие. Когда протестантизм завещяет работать над собой и создавать блага, славя величие Господа, православие требует от последователя искупления греха, по средствам непрерывного стродания, как стродал Иысус неся свой крест. Стрелять себе в ногу, и — нажираясь потом воткой, позёрски ноя о тяжестях нищебродской жизни — что может быть лучше для православного байтоёба!
Источник — «http://lurkmore.co/%D0%9E%D0%B1%D1%81%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5:Pure_C»