Когда использовать C над C ++ и C ++ над C?

Я познакомился с Computer Science чуть больше года, и по моему опыту кажется, что C и C ++ считаются «сверхбыстрыми» языками, тогда как другие, такие как Python и такие языки сценариев, < em> обычно считается несколько медленнее.

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

(Я также заметил, что файлы C ++ почти всегда имеют соответствующие заголовки, а файлы C - не так много). Но мой основной вопрос заключается в том, чтобы получить общее представление об интуиции, когда целесообразно использовать C над C ++, и когда лучше использовать C ++ над C. Кроме фактов, что (1) C ++ является объектно-ориентированным, тогда как C нет, и (2) синтаксисы очень похожи, а C ++ был намеренно создан, чтобы по-разному напоминать C, я не уверен, в чем их отличия. Мне кажется, что они (почти) идеально взаимозаменяемы во многих областях.

Так что было бы понятно, если кто-то сможет прояснить ситуацию! Благодаря

c++ c
165 голосов | спросил 2 revs, 2 users 93%
Dark Templar
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

12 ответов


184

Вы выбираете C, когда

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

Во всех остальных случаях вы должны выбрать C ++.

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
88

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

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

Другое время /причина использования C - предоставить набор функций, с которыми вы можете привязываться, по существу, от любого другого языка. Вы можете записывать эти функции в C ++, определяя их как функции extern "C" , , но , тем самым ограничивая эти функции представлением по существу C- «лицом к лицу» к классам мира, перегруженным функциям, шаблонам, функциям-членам и т. д., не нужно применять. Это не обязательно ограничивает разработку C хотя бы - вполне разумно использовать любые и всевозможные возможности C ++ internal , если внешний интерфейс выглядит как C.

В то же время, я должен сказать, что ответы @ Toll (для одного очевидного примера) имеют во многом что-то в обратном направлении. Разумно написанный C ++, как правило, будет как минимум с C, и часто, по крайней мере, немного быстрее. Считываемость, как правило, намного лучше, хотя бы потому, что вы не попадаете в лавину всего кода даже для самых простых алгоритмов и структур данных, всех ошибок и т. Д.

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

Автоматизированные инструменты - это, в основном, красная селедка, хотя верно, что писать C-парсер - это меньше работы, чем писать парсер C ++, реальность такова, что в конце концов практически нет никакой разницы. Очень немногие люди хотят или могут написать полезный парсер для одного. Таким образом, разумной отправной точкой является Clang в любом случае.

Как это бывает, C и C ++ довольно часто используются вместе в тех же проектах, которые поддерживаются теми же людьми. Это позволяет что-то, что в противном случае довольно редко: исследование , которое прямо, объективно сравнивает ремонтопригодность кода написанные на двух языках людьми, которые одинаково компетентны в целом (то есть, те же самые люди). По крайней мере, в связанном исследовании один вывод был ясен и недвусмыслен: «Мы обнаружили что использование C ++ вместо C приводит к улучшению качества программного обеспечения и снижению затрат на обслуживание ... "

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
24

Различия между C и C ++ уже перечислены подробно . Хотя иногда у людей могут быть законные причины выбора того или другого (C ++ для OOP или C, когда они чувствуют, что дополнительные функции C ++ добавляют, например, нежелательные накладные расходы), по моему опыту это обычно сводится к предпочтению. Что люди, работающие над этим файлом, знают лучше и лучше? Полагаю, что это причина большей части времени, так как это правда, что на этих языках рассматриваются критически важные приложения.

(Боковое примечание: посмотрите Линус Торвад 'rant о том, почему он предпочитает C на C ++. Я не обязательно соглашаюсь с его точками, но он дает вам представление о том, почему люди могут выбирать C над C ++. Скорее, люди, которые согласны с ним, могут выбрать C для этих причины.)

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
13

Основная проблема, отсутствующая в существующих ответах (на момент публикации) - это выбор.

Это просто. Если по какой-то совершенно иррациональной причине вы чувствуете, что исключения не стоят накладных расходов, тогда вам не нужно их использовать . У вас все еще есть шаблоны, RAII и стандартная библиотека, и никогда не пишите ни одного «броска». То же самое касается шаблонов. Если по какой-то причине вы чувствуете, что они вызывают безотзывное (и фактически важное, что только на вложенном) исполняемом раздувании, то неожиданно - вы можете использовать void * и sizeof (T) весь день. Ничто не заставляет вас использовать какие-либо функции C ++ над C.

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
9

Вещи о C ++, которые заставляют программистов C нервничать

У капота много волшебства; конструкторы, деструкторы, виртуальные методы, шаблоны и т. д., может сделать код C ++ намного проще и быстрее писать, чем эквивалентный код C, но сложнее понять и объяснить (в зависимости от того, насколько хорошо вы знаете C ++ и связанные с ним соглашения). Что-то простое, как Foo newFoo; может вызывать код lot , в зависимости от того, как конструктор для класса Foo (и любых классов зависит от ). Вот почему соглашение заключается в том, чтобы писать ++ it вместо it ++ при повторении через контейнер, поскольку postfix ++ часто включает дорогостоящий копирование.

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

  /* C версия * /
#include <stdio.h>
int main (void)
{
  char приветствие [] = «Привет, мир»;
  printf ("% s \ n", приветствие);
  return 0;
}
/* конец C версия * /

/* Версия на C ++ * /
#include <iostream>
#include <string>
int main (void)
{
  std :: string приветствие («Hello, world»);
  std :: cout <приветствие <станд :: епсИ;
  return 0;
}
/* конец C ++ версия * /
 

Идентичное поведение, а не большая разница в терминах источника, но в блоке SLES 10 я работаю с gcc 4.1.2, первый генерирует исполняемый файл размером ~ 9kb, тогда как второй занимает более 12.5kb (без оптимизации), почти на 28% больше. Тип C ++ string намного проще работать с IMO, чем с строковой библиотекой C, а потоки C ++ намного более гибкие и настраиваемые, чем потоки C, но для действительно такого мозгового кода, как это, они может не стоить накладных расходов.

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

Вещи о C, которые заставляют программистов на С ++ нервничать

C не является безопасным языком программирования каким-либо образом воображения; никакая проверка границ массивами не приводит к большому количеству эксплуататорского поведения (будь то через функцию получает ) или через scanf с помощью % s и % [). C ++, по крайней мере, дает вам контейнеры, которые генерируют исключения, если вы пытаетесь получить доступ за пределами их текущего диапазона; все C дает вам (если вам повезет) нарушение сегментации.

Управление памятью на C очень трудоемко и подвержено ошибкам, по сравнению с инструментами C ++. Если вы создаете свой собственный контейнер, вы несете ответственность за сопоставление всех вызовов malloc и free , убедившись, что выделение выполнено успешно, отбрасывая любые частичные распределения в событие ошибки и т. д. В C ++ вы просто добавляете элементы или удаляете элементы из контейнера. Если есть проблема, будет выбрано исключение.

Аналогично, обработка ошибок в C - боль в заднице по сравнению с инструментами C ++ (а именно исключениями). Что действительно забавно, когда вы выделили кучу памяти, а затем ударили стену в своей обработке; поскольку вам нужно отступить, вы должны освободить эту память в правильном порядке. С принципами C ++ и RAII это (относительно) легко сделать.

Итак, когда я использую один над другим?

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
9

Bjarne Stroustrup поддерживает список приложений и компаний , которые используют C ++; вы можете спорить о процедурных программах OOP, которые вы хотите, но вы не можете спорить с результатами отрасли за последние 20 лет.

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

Стандартная библиотека C ++ (STL), сама по себе с только векторами и картами, является достаточной причиной для использования C ++.

C обычно используется для встроенных систем.

Я бы лично использовал C только в том случае, если есть библиотека, имеющая только C API.

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
9

Я бы сказал, что главная причина, по которой я бы выбрал C над C ++, - это только тогда, когда мне придётся прибегнуть к «Это должно быть 1000% стабильным», что-то вроде NASA.

C ++ составляет ~ 99% C, когда мы смотрим на производительность, и это намного более продуктивно. Поэтому даже в C вы можете написать код, который будет быстрее, чем C ++ (вы можете использовать подмножество C ++ без исключений, виртуальные потоки, абстракции и т. Д.), Но это в основном C), время, чтобы оптимизировать каждую проклятую вещь в то время как STL тестируется и делает это уже, будет стоить вам больше, чем крошечное увеличение производительности, которое вы могли бы достичь, или жертву, потому что алгоритмы STL были написаны группами экспертов, и вы, вероятно, не являетесь экспертом во всем.

С другой стороны, C ++ имеет тонну абстракций. Когда это обстоятельство течет, это приводит к неприятностям. И есть мало людей, которые знают 100% C ++ gotchas, в то время как, я думаю, есть больше, которые знают все C gotchas, поэтому написать решение, где каждый шаг полностью понятен всем членам команды, намного проще в C.

Пример. Знаете ли вы, что когда shared_ptr <smthn> переполнит счетчик ссылок, будет ли он выдавать исключение? Такие вещи не круты, когда Шаттлу приходится возвращаться в атмосферу, по крайней мере, я так думаю.

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
6

C - это портативная сборка с лучшим синтаксисом, позволяющая программисту полностью управлять всем .

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

  • не используйте больше памяти, чем хотите
  • не имеют доступа к страницам памяти willy nilly (vtable может быть где угодно)
  • не ссылаются на много кода случайно

И хотите, чтобы с чем-то действительно было просто работать, поскольку вы ориентируетесь на производительность.

У него просто нет сюрпризов, и это очень ценно.

Если вы хотите (и я рекомендую), прочитайте JSF) о том, что вам нужно подумать при написании C ++ для управления военной авионикой. Здесь много ловушек, о которых вам нужно знать, и это может вас поймать. Бьярн был частью этого документа, поэтому он знает, что это значит.

Кроме того, C компилируется как ошпаренный тролль, пораженный молнией. C ++, OTOH, вероятно, спонсировались теми же людьми, которые инвестировали в компании SSD. :)

(Лично я бы предпочел C ++, но мне это не нравится ... .-P)

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
2

(если у вас одинаковое знакомство с обоими языками)

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

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
1

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

Я вижу, что язык C идеален в 4-х областях: 1) Я думаю, что это лучший язык для использования при первом изучении любого типа программирования [в сочетании с некоторыми сборками и знанием машинного кода], 2) он отлично подходит для написания драйверов, 3) встроенное программное обеспечение и 4) системное программное обеспечение на самом низком уровне.

C ++ - это объектно-ориентированный язык, но он также может быть процедурным (очень сильно на пути C). Если вы работаете над крупномасштабными проектами, программным обеспечением на основе графического интерфейса, игровым программным обеспечением и другими типами графически-интенсивного программного обеспечения, то я считаю, что C ++, Java или даже Objective-C - ваш лучший выбор. Тем не менее, есть много программ командной строки или системного программного обеспечения, где вы можете найти C ++, чтобы он был таким же хорошим или лучше, чем C.

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
0

По моему мнению, в этом обсуждении отсутствует одна точка: в C проще упростить создание стабильного бинарного интерфейса из библиотеки. Как для использования с другими языками, так и с C ++.

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

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

Я наблюдаю это на Solaris относительно часто. В дистрибутиве и разных поставщиках программного обеспечения, как правило, используется Sun Studio, особенно в системах Sparc, она часто обеспечивает лучшие результаты. Однако проекты с открытым исходным кодом для человека написаны с кодом gcc. Может быть довольно немного боли, чтобы заставить их работать вместе.

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
0

C, вероятно, предпочтительнее C ++, когда генерируется код C (например, в реализациях языков более высокого уровня). Например, существует несколько Lisp-подобных компиляторов, которые испускают код C (например, Курица , Scheme48 ...), но я не знаю никого, который испускает подлинный код на C ++ (my инструмент MELT испускает код C ++, но я не буду называть этот код подлинным C ++-кодом, он использует очень мало возможностей C ++).

C-код также легче доказать полуавтоматически. Статические анализаторы, такие как Frama-C (где вы комментируете свой код C с комментариями ACSL, чтобы помочь понять причину вашего кода ) доступны для C, но не так много для полного C ++ 11.

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132