Кроме ООП, почему C++ лучше, чем C? [закрытый]

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

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

Использование некоторых из наиболее простых для понимания и использования элементов стандартной библиотеки, таких как std :: string и iostreams, и даже std :: vector в качестве "лучший массив"; вам не нужно много изучать C ++ или понимать ООП, чтобы воспользоваться преимуществами этих улучшенных интерфейсов.

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

Не-объектно-ориентированные функции, которые есть в C ++, которых нет в C:

1. Шаблоны
2. Перегрузка функций
3. Ссылки
4. Пространства имен
5. Вы можете использовать struct s и enum без записи struct или enum перед каждым объявлением или с использованием typedefs.
6. Даже если вы не определяете свои собственные классы, использование строковых и контейнерных классов C ++ по-прежнему часто удобнее и безопаснее для работы, чем строки и массивы в стиле c.
7. Типовая безопасность (даже если некоторые называют ее слабой)
8. Исключения
9. Объявления переменных в условных выражениях, C99 имеет это только в для

Я большой поклонник C , который со временем стал большим поклонником C ++ . Одной из основных причин этого является STL ( Стандартная библиотека шаблонов ) и Boost .

С их помощью очень легко писать мощные переносимые приложения.

Ссылки создаются автоматически и намного безопаснее по сравнению с указателями, стандартная библиотека гораздо более обширна, шаблоны делают код чрезвычайно настраиваемым, значительно быстрее и безопаснее. C ++ предлагает фантастическое использование / повторное использование и организацию кода. Кроме того, если вы не слишком полагаетесь на ООП, значит, вы делаете это неправильно. Бывают случаи, когда объекты не подходят, но это не большинство сценариев.

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

Многие функции C99 очень хороши и все еще не в C++.

[Примечание: это субъективный ответ, но сам вопрос имеет тенденцию вызывать субъективные ответы по своей природе].

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

С другой стороны, и я пытаюсь говорить очень обобщенно, C ++ действительно может облегчить написание более эффективного кода, особенно для кода, который должен работать с несколькими типами. Тесты qsort vs std :: sort - классический пример того, как C ++ с помощью шаблонов и встроенных функциональных объектов может предоставлять бесплатные абстракции. В C нужно было бы написать отдельный алгоритм сортировки для каждого типа вручную или вставить его в макрос для достижения сопоставимых результатов.

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

Что касается конкретных различий, sepp2k уже указал довольно исчерпывающий список.

Помимо положительных сторон, отмеченных sepp2k (и я согласен с ними), у него, безусловно, есть некоторые небольшие недостатки, которые напрямую не связаны делать с OO. Вспомним отсутствие __ VA_ARGS __ для препроцессора и контекстной чувствительности. Рассмотрим что-то вроде:

switch (argc) {
 case 1: /* empty statement */;
         toto T;
 case 2: break;
}

В C, когда компилятор встречает такой фрагмент кода и известны argc и toto , это действительно так. (Конечно, впоследствии мы можем получить предупреждение для унифицированного T, откуда мы его используем.)

В C ++ это зависит от типа toto . Если это POD, то все нормально (ну, как и для C). Если у него есть конструктор, код недействителен: переход к метке case пересекает инициализацию 'toto T' .

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

Одна «особенность», о которой не так много упоминалось (но я думаю, что она заслуживает внимания) состоит в том, что сообщество компиляторов C ++, похоже, готово приложить гораздо больше усилий для создания соответствующих реализаций. Когда стандарт, который в конечном итоге стал C89 / 90, был в работе, почти все поставщики компиляторов работали над соответствием последним проектам стандарта и (особенно когда стандарт был близок к завершению) действительно приложили много усилий для того, чтобы соответствовать максимально точному соответствию. как могли.

Это уже не так. Стандарт C99 был (очевидно, достаточно) завершен более десяти лет назад, но в основном до сих пор существует только одна реализация, которая делает серьезную попытку согласования со стандартом в целом (Comeau). Некоторые другие (например, gcc) добавили некоторые функции C99, но все еще не имеют достаточного количества других. Один (pcc) находится в довольно парадоксальном положении, добавив почти все функции, характерные для C99, но не очень близко соответствует требованиям C89 / 90.

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

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