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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/* C version */
#include <stdio.h>
int main(void)
{
  char greeting[] = "Hello, world";
  printf("%s\n", greeting);
  return 0;
}
/* end C version */

/* C++ version */
#include <iostream>
#include <string>
int main(void)
{
  std::string greeting("Hello, world");
  std::cout << greeting << std::endl;
  return 0;
}
/* end C++ version */

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

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

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

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

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

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

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

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

Бьярне Страуструп ведет список приложений и компаний , использующих C ++; Вы можете спорить о процедурном и ООП программировании сколько угодно, но вы не можете спорить с отраслевыми результатами за последние 20 лет.

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

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

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

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

Я бы сказал, что основная причина, по которой я бы выбрал C вместо C ++, заключается только в том, что мне приходится прибегать к таким вещам НАСА, как «это ДОЛЖНО БЫТЬ на 1000% стабильным».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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