Что делает C таким популярным в эпоху ООП? [закрыто]

91

Я много пишу на C и C ++, но не ожидал, что C будет вторым по популярности языком, немного уступая Java.

Индекс сообщества программистов TIOBE

Мне любопытно, почему в этом веке ООП C все еще так популярен? Обратите внимание, что 4 из 5 популярных языков программирования являются «современными» объектно-ориентированными языками.

Теперь, я согласен, что вы можете использовать ООП в C в некоторой степени, но это довольно болезненно и не элегантно (по крайней мере, по сравнению с C ++, я думаю). Итак, что делает C таким популярным? Это эффективность; быть на низком уровне; Подавляющее большинство библиотек, которые уже существуют или что-то еще?

GradGuy
источник
18
видеоигры, встроенные системы, аппаратное программирование (встроенное ПО), операционные системы и т. д.
25
Обратите внимание, что вы получаете только то, что измеряете - в случае TIOBE - количество посещений +"<language> programming"популярных поисковых систем. Сообщение в блоге «Почему никто больше не программирует на C» имеет значение для C в этом индексе. Черт, даже этот вопрос может сработать, как только Google его подберет.
40
Возраст ООП? это довольно смелое утверждение.
Махмуд Хоссам
57
У вас есть иллюзия, что ООП - это серебряная пуля, вы должны это быстро потерять, в ООП нет ничего особенного или «хорошего», это всего лишь одна из многих стратегий организации кода.
Райнос
23
@DeadMG: Пот, познакомься с чайником. Данные TIOBE могут быть ненадежными, но ваше лживое утверждение, что «оно не популярно», не имеет никакого источника или ссылки вообще. Если вы собираетесь оспорить предположение, лежащее в основе вопроса, по крайней мере, предоставьте некоторые доказательства, подтверждающие это.
Даниэль Приден

Ответы:

142

Несколько факторов, которые способствуют:

  • С вездесущ. Независимо от платформы, C, вероятно, доступен.
  • С является портативным. Напишите кусок чистого C, и он компилируется с минимальными изменениями на других платформах - иногда он даже работает «из коробки».
  • С был вокруг некоторое время. В те времена, когда UNIX завоевывал мир, C (выбранный язык программирования UNIX) разделял свое мировое господство и стал языком общения в мире программирования. Любой серьезный программист может ожидать , по крайней мере , сделать какой - то смысл куска C; то же самое нельзя сказать о большинстве других языков.
  • C по-прежнему является языком по умолчанию для систем UNIX и UNIX. Если вы хотите, чтобы библиотека преуспевала на земле с открытым исходным кодом, у вас должны быть достаточно веские причины не использовать C. Это частично связано с традицией, но больше потому, что C - единственный язык, который вы можете смело предполагать, чтобы он поддерживал любой UNIX-подобный система. Написание вашей библиотеки на C означает, что вы можете минимизировать зависимости.
  • С прост. Ему не хватает выразительности сложных ООП или функциональных языков, но его простота означает, что его можно быстро подобрать.
  • С универсален. Он подходит для встраиваемых систем, драйверов устройств, ядер ОС, небольших утилит командной строки, больших настольных приложений, СУБД, реализации других языков программирования и практически всего, что вы можете себе представить.
  • С быстро. Большинство реализаций C компилируются непосредственно в машинный код, и программист имеет полную власть над тем, что происходит на машинном уровне. Здесь нет интерпретатора, JIT-компилятора, виртуальной машины или среды выполнения - только код, компилятор, компоновщик и голый металл.
  • C является «свободным» (как в пивном, так и в речевом смысле). Нет ни одной компании, которая владеет и контролирует стандарт, есть несколько реализаций на выбор, нет проблем с авторским правом, патентами или товарными знаками при использовании C, и некоторые из лучших реализаций - с открытым исходным кодом.
  • C имеет большой импульс. Язык был популярен в течение десятилетий, поэтому существует огромное количество приложений, библиотек, инструментов и, прежде всего, сообществ для поддержки языка.
  • С зрелый. Последним стандартом, внесшим большие изменения, является C99, и он в основном обратно совместим с предыдущими стандартами. В отличие от более новых языков (скажем, Python), вам не нужно беспокоиться о том, что в ближайшее время могут произойти изменения.
  • С совместим. У большинства языков есть привязки для общения с C. Это означает, что можно разработать библиотеку на C, используя стандартные соглашения о вызовах, и быть уверенным, что почти любой другой язык может ссылаться на эту библиотеку. Чтобы назвать несколько популярных языков: C #, Java, Perl, Python, PHP могут без проблем связываться с библиотеками C.
  • C мощный: если язык не может что-то сделать, все популярные компиляторы позволяют встраивать ассемблерный код, который может делать все, что может аппаратное обеспечение. Переходно сочетаясь с вышеупомянутым пунктом о совместимости, это означает, что C может служить связующим звеном между языками более высокого уровня и «голым металлом» сборки.
tdammers
источник
9
Я думаю, что не все ваши аргументы верны. 1) C вездесущ. C ++ такой же вездесущий, как и C, поскольку существуют компиляторы C ++ to C. 2) C является портативным. То же самое с C ++. 3). С был вокруг некоторое время. То же самое с C ++. 4). С универсален. То же самое с C ++. 5) С быстро. То же самое с C ++. 6). C «бесплатно». То же самое с C ++. 7). C имеет большой импульс. То же самое с C ++ снова. 8) С зрелый. То же самое с C ++. Таким образом, вы на самом деле не отвечаете на вопрос.
Константин Соломатов
19
C11 - новейший стандарт, а не C99. Не то чтобы это действительно имело значение, так как все используют 89 год.
Pubby
53
@KonstantinSolomatov: Если вы пишете библиотеку, которая будет использоваться другими людьми, сделайте одолжение миру и напишите ее на C вместо C ++. Если вы не можете этого сделать, по крайней мере, напишите C API. Все во вселенной может так или иначе связываться с кодом C, обычно с минимальными усилиями. Напротив, у вас часто возникают серьезные проблемы с ABI при попытке вызова кода C ++ из другого кода C ++ , не говоря уже о других языках.
Даниэль Приден
37
@KonstantinSolomatov - тот факт, что существует необходимость в компиляторе C ++ to C, доказывает, что C - тот, который повсеместен.
детально
11
@KonstantinSolomatov: Пожалуйста, перестаньте думать, что C - это C ++. С не имеет замыканий. Некоторые расширения C делают (например, реализованные семейством компиляторов gcc), но сам C этого не делает (т. Е. Не входит в исходную спецификацию K & R или в какой-либо из окончательных стандартов C).
Донал Феллоуз
88

Я всегда склонялся винить популярность C в необходимости универсального языка ассемблера. Это сочетание специфики на уровне машины, стандартизации и экстремальной переносимости позволяет C функционировать как де-факто универсальный язык ассемблера, и поэтому я подозреваю, что его роль будет продолжаться бесконечно.

Я должен отметить, что я всегда немного удивлен, когда ООП представлен на курсах программирования как своего рода «конечная модель», которая является единственно возможной конечной точкой для хорошего программирования. Как и многие другие аспекты программирования, ценность ООП - это компромисс между многими конкурирующими факторами, включая то, как человеческий мозг организовывает информацию, как социальные группы поддерживают программное обеспечение в течение длительного времени, а в случае объектно-ориентированного программирования - некоторые довольно глубокие аспекты о том, как работает сама вселенная.

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

Объект в физике - это все, что поддерживает узнаваемую согласованность во времени. Это, в свою очередь, позволяет таким простым существам, как мы, с легкостью представлять объект, используя лишь небольшое количество битов, не подвергая опасности свое выживание. Но с точки зрения физики в целом, число вещей, которые вы должны сделать совершенно правильно, чтобы сделать такое упрощение простым и распространенным, удивительно велико. Как люди, мы не думаем обо всем этом, потому что, честно говоря, нас бы здесь не было, если бы это было не так.

Звучит слишком абстрактно? Это действительно не так. Представьте себе, например, попытку проложить дорогу к дому вашего друга, если вместо автомобилей вы столкнулись с быстро колеблющимися плазменными полями и мгновенными сгущениями вещества, движущимися с огромным диапазоном скоростей. Такой сценарий может довольно сильно сократить возможности социализации, да? Нам нужны объекты, мы являемся объектами, и существование объектов предоставляет нам огромный и критически важный уровень упрощения окружающей нас среды.

Итак, давайте вернемся к программному обеспечению. Что объекты в реальном мире говорят об объектах с точки зрения программирования?

Ну, во-первых, это означает, что то, что определяет «хороший» объект в программном обеспечении, должно в действительности заключаться в том, поддерживает ли тип данных, с которыми вы работаете, готовность к распознаваемому постоянству во времени .

С определением, самые простые формы ООП легко распознаются. Это те, которые немного справляются, используя только те данные, которые уже «прикреплены» или определены неким реальным, действительно физическим объектом, таким как человек, дом или машина. Даже сегодня это слишком часто единственное определение объектов, которые люди получают на курсах программного обеспечения. Это очень плохо, потому что даже тривиальные объектно-ориентированные программы нуждаются в более широком определении.

Вторая и гораздо более интересная категория объектов состоит из того, что я назову увековеченными событиями реального мира . Под «увековеченным» я подразумеваю вещи, которые, по крайней мере, кратко существуют как четко определенная сущность или совокупности в реальном мире, но затем рассеиваются и перестают существовать как физически значимые совокупности. Симпозиум является отличным примером: симпозиум существует в течение короткого времени как прилично четко определенный набор мест и людей. Но, увы, даже лучшие конференции должны заканчиваться, и отдельные составляющие их части переходят к другим видам деятельности.

Но используя компьютеры и сети, мы можем сделать так, чтобы такой переходный симпозиум казался долгосрочным объектом, захватывая и поддерживая память о нем как программный объект. Очень многое из того, что мы делаем с компьютерами и базами данных, сводится к такого рода иммортализации переходных событий, когда мы фактически пытаемся сделать нашу настоящую вселенную более богатой, захватывая и расширяя ее таким образом, что физически не может существовать. Например, ты видел настоящего Пандору в последнее время? Такие захваты и расширения реальных произведений помогают удивительным образом обогатить и расширить нашу собственную жизнь, экономику и выбор. Для меня это является сердцем объектно-ориентированного программирования, местом, где оно оказало и продолжает оказывать наиболее значимые воздействия.

Последняя категория ООП состоит из объектов, которые не имеют тесной связи с внешними событиями, но вместо этого являются инфраструктуройнеобходимо поддержать наше продолжающееся расширение реальности, используя увековеченные объекты из реального мира. Здесь вы можете спуститься до (полу) металла компьютера, создавая части постоянной реальности, которые подобно химическим элементам реального мира можно быстро и интересным образом комбинировать для создания новых внутренних миров. Мобильные вычисления помогли стимулировать развитие такого высоко рекомбинаторного подхода, который во многом повторяет рекомбинаторные особенности физического мира. Это также сложно: то, что может показаться хорошим выбором, может со временем оказаться неожиданно плохим, обычно потому, что оно блокирует разнообразие и расширение, а не поддерживает его.

Эта последняя категория также указывает на риски использования только одной модели для программирования, поскольку, как и в реальном мире, в программируемых мирах также нужны процессы, которые нехорошо соответствуют относительно неизменным объектам. Земля полна объектов, но солнце наполнено высокодинамичными потоками энергии, которые, в конечном счете, необходимы для "вождения" объектов и деятельности на Земле с более низкой энергией. Аналогично, при создании вычислительных миров существуют случаи, когда вам приходится иметь дело с потоками, преобразованиями и быстро меняющимися контекстами, которые, хотя и не очень объектно-подобны сами по себе, тем не менее абсолютно важны для включения более простых, более дружественных человеку объектов, используемых на более высоких уровнях. , Не случайно, что большая часть программирования, выполняемого на уровне ядра, не является явно объектно-подобной или что она в значительной степени опирается на языки типа C, которые более ориентированы на обработку. Это более глубокие области, которые дополняют увлекательное разнообразие, которое мы видим выше в мире, созданном компьютером.

Другая область, в которой ООП может пойти наперекосяк, - это слишком большое внимание к старым объектным концепциям.

Объекты в реальном мире, и особенно живые объекты, обладают абсолютно удивительным уровнем способности взаимодействовать со своей средой сложными и тонкими способами. Композиционные виджеты, которые просматривают друг друга, выполняют некоторые проверки совместимости и работоспособности и, возможно, даже находят новые способы взаимодействия, намного ближе к реальной биологической концепции объектов, чем простые структуры и простые схемы наследования, к которым мы стремимся. сосредоточиться на (обычно по необходимости!) на уровне кода. Это одна из областей роста объектов в кибер-мире, более «агентоподобные» подходы, где реактивность к среде является нормой даже внутри самого программирования.

И так много для моей "критики" ООП! Тем не менее, я надеюсь, что я указал, почему создание более богатого кибермира означает охватывать разнообразие стилей программирования, а не предполагать, что «только один» - это все, что нужно. Я чувствую, что действительно интересные вещи еще впереди, независимо от того, насколько обыденным является то, что мы делаем сейчас!

Terry Bollinger
источник
18
Я уверен, что довольно много людей пропало в разделе «Читайте дальше, только если вы заинтересованы в изучении физического уровня». Я рад, что я не сделал. Это тот тип мышления, который расшатывает основы нашего понимания и, вероятно, единственный способ добиться заметного прогресса. Спасибо за отличное чтение.
Мэтт Эш
@Raynos, $ MattEsch, спасибо вам обоим за добрые слова, и я рад, что вам было интересно!
Терри Боллинджер
1
Зарегистрируйся на сайте просто чтобы иметь возможность проголосовать - это глубокий, великолепный ответ. =)
sgorozco
2
В соответствии с вашими мыслями, я довольно давно программировал и стал фанатом ООП, так как я действительно увидел, что мои навыки кодирования значительно улучшились, когда я его принял. Однако опыт показал мне, что принуждение всего к тому, чтобы стать объектом, действительно может быть вредным. Теперь я отказываюсь от средств объектно-реляционного отображения (что за беспорядок) или схем полных сериализаций графов объектов, которые используют пропускную способность 1000% по сравнению с простым двоичным протоколом, который просто передает по проводам нужное количество двоичных данных, которое необходимо при момент Спасибо за отличное чтение.
sgorozco
2
Этот ответ также является ответом на вопрос, зачем нам все еще нужен SQL!
HLGEM
25

Во-первых, вам не нужен ООП для всего, несмотря на то, что догмы об этом были популяризированы. В отличие от Java, C допускает указатели на функции и даже замыкания, которые открывают двери для функционального программирования и решают довольно большую часть проблемных OOP-дескрипторов пространства, потому что он предоставляет средства для внедрения зависимостей. Также осторожное использование макросов может на самом деле создавать очень хорошие вещи, как доказывает sglib .

Странным образом можно увидеть C как хороший компромисс между Java и C ++. Обратите внимание, я не говорю, что C в любом случае является смесью обоих. Но в отличие от Java это довольно мощный язык, в то время как в отличие от C ++ он имеет управляемую сложность.

Это старый язык, который стал надежным и последовательным, но не стал более сложным. И все это в стороне, у этого есть гигантская экосистема, и это просто бежит всюду.

оборота back2dos
источник
11
Функциональное программирование великолепно, никаких возражений по этому поводу. Но C - довольно плохой язык для функционального программирования. Замыкания / блоки являются непереносимыми взломами и идут с уродливым синтаксисом (я уверен, что и ошибки). Даже игнорируя все это, вы все равно должны заботиться об управлении памятью. C - это полезный язык, но, как и в случае с любым другим языком, вы просто усложняете свою жизнь, если вы злоупотребляете ею, используя парадигму, для которой он не был создан. Вы также можете эмулировать функциональное программирование в Java (см. Guava ), но это тоже нехорошо.
7
Очень сложно программировать в функциональном стиле без сборщика мусора.
Константин Соломатов
@KonstantinSolomatov: Во-первых, это очень субъективно. Во-вторых, вы можете добавить сборку мусора в C, если это необходимо.
back2dos
Если вы хотите найти компромисс между Java и C ++, попробуйте Obj-C :) Определенно то, что должен попробовать каждый программист C / C ++.
Sulthan
21

C имеет ABI (двоичный интерфейс приложения), а C ++ - нет. Это делает C более полезным, чем C ++, в некоторых случаях. Если я собираюсь написать библиотеку и иметь возможность поставлять двоичные файлы для использования другими людьми, C ++ - неподходящий инструмент для работы. Если я собираюсь написать библиотеки, которые будут использоваться другим языком снова, C - правильный инструмент для работы. Я никогда не слышал о языке, который бы не поддерживал FFI (интерфейс внешних функций) для C, с другой стороны, C ++ не будет работать с библиотеками, написанными на C ++, если используются разные компиляторы.

По сути, это сводится к тому, что C выполняет роль, для которой C ++ не подходит.

stonemetal
источник
2
Ммм .. а С, помидор и сыр рулет!
DeadMG
3
Ну, C ++ имеет ABI. Просто C ABI прочен как рок, а C ++ меняется слишком часто. Плюс много C ++ - это шаблоны, скомпилированные в используемое приложение, поэтому вы не можете его обновить. Когда вся функциональность скрыта за вызовами функций, можно исправить библиотеку и сохранить работу приложения.
Ян Худек
12

Одно из преимуществ использования C над такими языками, как C ++ или Java, заключается в том, что под капотом не происходит много магии. Конструкторы не запускаются при выделении элементов, а деструкторы не запускаются, когда объекты выходят из области видимости. Там нет названия искажения и нет vtables. Производительность легче прогнозировать; вам не нужно беспокоиться о том, что сборщик мусора прервет рутину и сместит время.

Конструкторы, деструкторы, искажение имен, vtables, сборщики мусора и т. Д. Могут облегчить некоторые сложности в написанном вами коде, но затем эта сложность становится частью самого языка, где вы практически не можете его контролировать . Вы можете столкнуться с более длительным временем сборки (раздражающим, но допустимым), большим объемом памяти во время выполнения (может или не может быть терпимым) или более низкой производительностью. С C вы можете избавиться от некоторых из этих сложностей, пока не останетесь с необходимой вам функциональностью .

Например, с stringтипом данных C ++ легче работать со световыми годами, чем со строками в стиле C, но это довольно тяжелый кусок кода, который добавляет некоторый вес вашему размеру изображения. Я редко видел, чтобы кто-нибудь в полной мере использовал stringвозможности какой-либо одной программы. Строки в стиле C, с которыми труднее работать, налагают меньше штрафов с точки зрения времени выполнения и размера изображения, и для конкретной проблемы могут быть более привлекательными по этой причине.

Джон Боде
источник
2
Штраф за время выполнения - нонсенс. C-строки (с нулевым символом в конце) гораздо менее эффективны, чем строки C ++. Кроме того, строковый класс может быть таким же компактным, как C, если вы не перетаскиваете его целиком std.
Pubby
1
Цепочка инструментов, которая не удаляет неиспользуемые функции string, которые не используются, если вы статически связываете CRT - это цепочка инструментов, которая не стоит того, чтобы ее использовать.
Билли Онил
10
Глупая вещь, я работаю с библиотекой , где std::stringне является сложным достаточно . Если вы действительно серьезно относитесь к строкам, как с точки зрения производительности, так и возможностей, вы вернулись к использованию C и снова все делаете сами, хотя, char*конечно , не используете простые старые s. (Строки на удивление сложны, даже если вы ожидаете, что они будут сложными.)
Донал Феллоуз
1
@DonalFellow Интересно. Именно поэтому стандарт C всегда отказывался от таких вещей, как строки и хеш-таблицы, хотя их отсутствие иногда раздражало меня.
Инженер
@ArcaneEngineer: основной отсутствующий тип данных в C - это тип "slice of T []", который объединяет T * и size_t, может быть проиндексирован как массив, может быть разложен в T * и может быть неявно преобразован из любой тип T [n] (размер автоматически указывается компилятором). Такой тип может позволить автоматическую проверку границ во многих случаях, когда это невозможно, в то же время делая многие виды кода более понятными и удобочитаемыми.
суперкат
11

Встроенные системы и драйверы обычно программируются на C. Помимо этого, существует множество устаревших систем C, которые все еще поддерживаются и расширяются.

EricSchaefer
источник
2
Да, C работает на всем. И это довольно легко выучить язык (по сравнению с C ++).
BenjaminB
10

То же самое, что делает ручной молот популярным в эпоху пневматических молотков (пневматических молотков): C по-прежнему является подходящим инструментом для определенных задач.

скоро
источник
6

Простота, последовательность и точность.

Это просто - вам не нужна сложная среда разработки, обширные библиотеки или виртуальная машина.

Это согласуется - большинство C, написанных 10 лет назад, могут компилироваться сегодня.

Точность - это позволяет вам опуститься до уровня машины, зная места памяти по мере необходимости. Это отлично подходит для производительности и встроенного оборудования.

Это не для всех, но это все еще полезный инструмент.

MathAttack
источник
5
Более того, есть большая вероятность того, что код, скомпилированный 10 лет назад, может выполняться сегодня.
Донал Феллоуз
@DonalFellows: И для приложений, использующих плагины, есть большая вероятность того, что приложение, написанное, построенное и выпущенное (в исполняемой форме), сегодня сможет использовать плагины, скомпилированные с инструментами сборки, которые даже не были разработан еще.
суперкат
6

Я привожу два момента из другого ответа, потому что они точно отражают причины, по которым я все еще время от времени пользуюсь Си (хотя это не мой основной язык выбора):

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

Я думаю, что это очень верно. Я выучил C в начале ночных сороковых: это было просто, мало ключевых слов и конструкций, большая часть работы выполнялась библиотеками. Тогда я не использовал C в течение нескольких лет. Примерно в 2002 году мне понадобилась быстрая реализация алгоритма, я установил компилятор C и реализовал его. Я знаю язык, знаю, для чего он хорош, для чего он не годится (я бы никогда не реализовал веб-приложение на C!), И это как раз там, когда мне это нужно. Без сюрпризов.

С C ++ у меня был другой опыт. Я узнал об этом примерно в 1995 году, и это означало большой переход парадигмы с императива на ООП. Большой! Я использовал его для нескольких проектов до 1999 года. В течение нескольких лет я не использовал C ++, и когда я снова поднял его (2008), я обнаружил множество новых функций уже в языке, и даже более запланированных (в то же время введенных в C ++). 11). У меня возникло ощущение, что я должен снова выучить язык.

Как разработчик, я предпочитаю зрелые, стабильные языки. Мне нравится изучать язык один раз, понять его принципы дизайна, для чего он нужен, и использовать его, когда я считаю, что это правильный инструмент для работы. Мне также нравится изучать разные языки и выбирать язык, который мне подходит (C, C ++, Java, Scala, Haskell и т. Д.). Что мне не нравится, так это снова и снова изучать один и тот же язык, потому что он развивается все дальше и дальше и никогда не достигает зрелости.

ИМХО, язык программирования должен иметь четкий, слаженный и стабильный дизайн. Мне нравится подход таких дизайнеров, как Никлаус Вирт: каждый раз, когда он чувствовал потребность в другом языке, он проектировал новый (Паскаль, Модула-2, Модула-3, Оберон). Мне не нравятся языки, которые подвергаются важным изменениям каждые 5-10 лет: они похожи на движущиеся цели, и я никогда не чувствую, что стоит потратить время на их глубокое изучение, потому что версия, которую я изучаю сейчас, вероятно, устареет через несколько годы в любом случае.

В этом смысле C является IMO победителем: это хорошо для некоторых приложений и менее подходит для других, но имеет то преимущество, что оно простое и относительно стабильное.

Джорджио
источник
4

Я удивлен, что никто еще не упомянул, что Хуже лучше . На данный момент ему более 20 лет, но все еще стоит читать. Несмотря на то, что время от времени он немного издевается, он очень хорошо показывает, как и почему средство часто побеждает идеал, используя C (в сравнении с LISP) в качестве одного из центральных примеров.

Дэн Мартинес
источник
Вещи, которые я помещаю в категорию «хуже, но лучше»: английский, PHP, Windows. .. Макдональдс может быть. Хотя я все еще завидую / предпочитаю испанский, Python, Linux и Artisan French Cooking; насколько это возможно, если не всегда возможно.
ThorSummoner
1

Вы, вероятно, хотели спросить, почему люди используют C вместо C ++, несмотря на тот факт, что когда у вас есть компилятор C, у вас также обычно есть компилятор C ++.

  • Язык C намного проще, чем C ++. Я не знаю ни одной компании, которая использует полный стандарт C ++ в своем соглашении о кодировании. Взгляните на стиль кода Google C ++ в качестве примера: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
  • С гораздо быстрее компилируется. Благодаря отсутствию сложных для компиляции конструкций.
Константин Соломатов
источник
Эта ссылка не работает.
ar2015
0

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

DeadMG
источник
10
Тот факт, что TIOBE ничего не стоит, не означает, что C не популярен
Raynos
Тем не менее, он определенно опровергает аргумент, представленный в ФП, о том, что C популярен, и поэтому ему нужно что-то использовать.
DeadMG
2
Лучшим показателем популярности C является то, что почти на каждой платформе есть компилятор C
Raynos
@Raynos: это совсем не измерение. Единственное, что означает, это то, что это легко реализовать. В нем ничего не сказано о том, сколько людей его используют или почему.
DeadMG
2
Не совсем, я с радостью принимаю противоположные точки зрения. В вашем однострочном ответе, кажется, мало мыслится, и вы с аргументами и неконструктивны в своих ответах.
Mattnz
0

Много устаревшего программного обеспечения

Многие компании не могут изменить сразу весь свой код на C ++ или аналогичный.

Многие компании не могут позволить себе изменить свой код.

Многие компании могут позволить себе изменить свой код, но им все равно, или они «дешевы».

Многие компании находятся в процессе миграции, но еще не закончили.

Ориентация на поиск предметов

(Не объектно-ориентированный) Исходный код C, разработанный как объектно-ориентированный исходный код C, приложения, которые смоделированы с помощью Object Orientation и закодированы с использованием «чистого C», или инструменты, которые переводятся из «C ++» или других программных продуктов OO. Ланг в C.

Я слышал, что некоторые видеоигры сделаны таким образом. Некоторые кроссплатформенные инструменты, а также библиотека визуального интерфейса GTK (GObject, GLibrary) для дистрибутивов ОС Linux GNOME.

umlcat
источник
3
Вторую половину этого ответа необходимо отменить.
Арамис
@aramis. Вторая часть означает: многие коды, по-видимому, передаются непосредственно в «C», но на самом деле на другом языке и транслируются в «C»
umlcat
0

Я вижу, что некоторые из респондентов рассказывают, почему C является самым популярным, он существует уже давно, доступен на большинстве платформ, бесплатен и т. Д.

Но то же самое можно сказать и о других языках, например, о бесплатном Pascal - он бесплатный и поддерживается практически на всех платформах.

Паскаль был изобретен около 1970 года, С был изобретен около 1972 года, поэтому я думаю, что Паскаль был примерно так же долго, как С.

Лично я думаю, что C - самый популярный язык, потому что есть только больше открытого исходного кода, доступного для повторного использования любым. И да, это более низкий уровень, чем у Pascal, поэтому он приближается к сборке, но намного более читаем, чем сборка.

Я думаю, что существует слишком много языков программирования. Как программисты, мы должны знать большинство важных, но, в конце концов, в этом не должно быть необходимости. Один язык программирования может быть реализован, чтобы делать все это от создания веб-сайтов до компьютерных игр для iOS.

Кажется, C - это тот глобальный язык, но я бы хотел, чтобы это было что-то вроде Object Pascal. Почему Object Pascal, это более читаемый язык программирования, ООП-код, как правило, более пригоден для повторного использования и менее подвержен ошибкам (на мой взгляд), чем C.

Очень большими приложениями легче управлять с помощью Object Pascal, чем C / C ++.

Что касается языка программирования, существовавшего с 70-х годов, и не любящих языков, которые меняются каждые 5 или 10 лет. Со временем технологические достижения и методы программирования совершенствуются. Если языки меняются радикально каждые несколько лет, то, вероятно, это не было хорошо продумано разработчиком. Но с 1970 по 2012 год - это почти полвека, поэтому можно вносить изменения в язык в то время, чтобы включать в себя достижения, используемые в разработке программного обеспечения.

Сам C был пересмотрен несколько раз. Так что это не лучше, чем другие языки с этой точки зрения.

Серхио Фернандес
источник
3
Одна проблема с Pascal заключалась в том, что «официальная» версия языка не учитывала некоторые очень необходимые функции. Некоторое время на ПК и Macintosh были компиляторы Pascal, которые были гораздо более удобны в использовании, чем любые компиляторы C, существовавшие в то время, но такие компиляторы добавляли языковые расширения, которые не поддерживались никаким «официальным» стандартом. Я думаю, что если бы была попытка сделать официальный стандарт, кодифицирующий такие расширения, Паскаль мог бы заменить этот взлом языка, известного как «C».
суперкат
0

Потому что C имеет огромную базу пользователей. Да, это немного ловушка, но когда я задаю вопрос о C в StackOverflow, я получаю ответ почти мгновенно. Тот же вопрос о Python может занять несколько часов, чтобы получить ответ.

Что касается C ++, IMO сложнее в освоении. Более того, после 10-летнего опыта ООП я обнаружил, что это не всегда полезно, и часто вместо этого проще использовать процедурное программирование.

PUK
источник
Вы сравнивали задавать ТАК вопросы для C # или Java?
комнат
@gnat это был отдельный пример C v Python (к которому, кстати, задано больше вопросов!). У меня нет опыта работы с C # (вы заметили, что я не задаю SO вопросов по C # или jav?)
puk
Хех, я считаю, что сообщество #python в StackOverflow почти всегда очень быстрое. Хотя я был бы удивлен, если бы сообщество C превзошло сообщество javascript за скорость ответов. (Главным образом из-за объема)
ThorSummoner