Личные инструменты

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

Материал из Lurkmore

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

Содержание

[править] Статья хороша

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

Статья в ужасном состоянии. Аффтарские грамматика, пунктуация и способ изложения мыслей будят во мне угнетателя. Нет пути. --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). Прошу школоту пройти на хуй. 

    >Автор - школьник еще тот. Пхп и перл - интерпретируемые языки, а не компилируемые.

[править] Статья безграмотна

  • «вменяемый 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, так чисто для справки. Чем сложней язык тем больше вероятность допустить "неявную ошибку". Спорить будем?

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

Быдлокодерам: Шарп не Ъ.--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++ можно найти в приложении к Оруэллу

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

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

[править] О быдлокодерах

Быдлокодеры на Си таки пишут, не надо. Грызут кактус но пишут. Правда большинство быдлокодеров уже давно свалило на 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 (виртуальная таблица функций)

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

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

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

Источник — «http://lurkmore.ru/Обсуждение:Pure_C»