Почему искусственно ограничивать свой код C?

Ответ 1

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

C - полный язык программирования. C не является произвольным подмножеством С++. C не является подмножеством С++ вообще.

Это действительно C:

foo_t* foo = malloc ( sizeof(foo_t) );

Чтобы скомпилировать его как С++, вам нужно написать:

foo_t* foo = static_cast<foo_t*>( malloc ( sizeof(foo_t) ) );

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

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

Принимая первый файл C в проекте, над которым я работаю, это происходит, если вы просто меняете gcc std=c99 на g++:

sandiego:$ g++ -g  -O1 -pedantic -mfpmath=sse -DUSE_SSE2 -DUSE_XMM3  -I src/core -L /usr/lib -DARCH=elf64 -D_BSD_SOURCE -DPOSIX -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112L -Wall -Wextra -Wwrite-strings -Wredundant-decls -Werror -Isrc  src/core/kin_object.c -c -o obj/kin_object.o | wc -l
In file included from src/core/kin_object.c:22:
src/core/kin_object.h:791:28: error: anonymous variadic macros were introduced in C99
In file included from src/core/kin_object.c:26:
src/core/kin_log.h:42:42: error: anonymous variadic macros were introduced in C99
src/core/kin_log.h:94:29: error: anonymous variadic macros were introduced in C99
...
cc1plus: warnings being treated as errors
src/core/kin_object.c:101: error: ISO C++ does not support the ‘z’ printf length modifier
..
src/core/kin_object.c:160: error: invalid conversion from ‘void*’ to ‘kin_object_t*’
..
src/core/kin_object.c:227: error: unused parameter ‘restrict’
..
src/core/kin_object.c:271: error: ISO C++ does not support the ‘z’ printf length modifier
src/core/kin_object.c:271: error: ISO C++ does not support the ‘z’ printf length modifier

Всего 69 строк ошибок, четыре из которых являются недопустимыми преобразованиями, но в основном для функций, которые существуют в C99, но не в С++.

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

Поэтому неправильно предположить, что

Компилятор

[a] C почти наверняка действительно является компилятором С++, поэтому нет никаких последствий для стоимости программного обеспечения

При переносе существующего кода C в процедурное подмножество С++ часто возникают значительные последствия для затрат.

Таким образом, предлагая "использовать класс std:: queue С++" в качестве ответа на вопрос, который ищет библиотечную реализацию очереди в C, означает "использовать цель C" и "вызывать класс Java java.util.Queue" используя JNI 'или' вызов библиотеки CPython '- Objective C на самом деле является надлежащим надмножеством C (включая C99), а библиотеки Java и CPython оба вызываются непосредственно из C без необходимости связывать несвязанный код с языком С++.

Конечно, вы можете предоставить C-фасад для библиотеки С++, но как только вы это сделаете, С++ не отличается от Java или Python.

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

Я ненавижу программирование на С++.

Ответ 5

Несколько причин могут быть:

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

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

Ответ 6

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

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

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

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

Ответ 7

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

В С++ также есть шаблоны. Я ненавижу и люблю их, но если кто-то говорит, что он или она полностью их понимает, я называю его лжецом! Сюда входят писатели-компиляторы, а также люди, участвующие в определении стандарта (что становится очевидным, когда вы пытаетесь его прочитать). Есть так много абсурдно вводящих в заблуждение угловых случаев, что просто невозможно рассмотреть их все, пока вы пишете реальный код. Мне нравятся шаблоны С++ для их чистой власти. Удивительно, что вы можете с ними сделать, но они также могут привести к самым странным и трудным для поиска ошибок, которые можно (не) представить. И эти ошибки на самом деле происходят и даже редко. Чтение о правилах, используемых для разрешения шаблонов в С++ ARM, почти заставляет мою голову взорваться. И это дает мне плохое ощущение потерянного времени, когда приходится читать сообщения об ошибках компилятора длиной в несколько символов, для которых мне нужно уже 10 минут или больше, чтобы понять, что компилятор действительно хочет от меня. В типичном коде С++ (library) вы также часто находите много кода в файлах заголовков, чтобы сделать возможными определенные шаблоны, что в свою очередь делает циклы компиляции/выполнения болезненно медленными даже на быстрых машинах и требует перекомпиляции больших частей кода, когда вы что-то меняете есть.

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

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

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

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

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

Жизнь коротка...

Ответ 8

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

Говоря по опыту в унаследовании и поддержке обоих: ужасный дизайн на C трудно понять, раскрутить и реорганизовать во что-то полезное.

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

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

Ответ 9

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

• Классы и функции-члены имеют нулевые накладные расходы по сравнению с обычными функциями (если вы не используете виртуальные функции, и в этом случае нет накладных расходов по сравнению с указателями функций)
• Шаблоны имеют очень мало накладных расходов (чаще всего нет накладных расходов)

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

Ответ 10

Зачем ограничивать разговор на английском языке? Возможно, вы были бы более творческим автором на сербском языке.

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

Ответ 11

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

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

Ответ 12

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

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

Ответ 13

Я хотел бы ответить на ответ Дэна Олсона. Я считаю, что люди боятся потенциально опасных и контрпродуктивных особенностей С++, и это оправданно. Но в отличие от того, что говорит Дэн, я не думаю, что просто принятие решения по стандарту кодирования является эффективным, по двум причинам:

• Стандарты кодирования могут быть трудно строго соблюдаться
• Это может быть очень сложно придумать.

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

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

(Альтернатива, что стандарт не пересматривается на шаге 3, является эмпирически слишком невероятным для рассмотрения и не будет намного лучше в любом случае.)

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

Ответ 14

Я использую C или, по крайней мере, экспортирую C-интерфейс при написании кода библиотеки.

Мне не нужны неприятные проблемы с ABI.

Ответ 15

Один момент, который я еще не видел, поднял, что я считаю самым важным:

Большинство библиотек, которые я использую на ежедневной основе, являются библиотеками C со связями для Python, Ruby, Perl, Java и т.д. Из того, что я видел, гораздо проще обернуть библиотеки C с 19 различными языковыми связями, чем это обернуть библиотеки С++.

Например, я узнал Cairo один раз и с тех пор использовал его на 3 или 4 разных языках. Большая победа! Я бы предпочел написать программу, которая может быть использована снова в будущем, и писать ее, которая может быть легко принята на другие языки программирования, является крайним случаем этого.

Я знаю, что возможно связывать библиотеки С++, но AFAICT это не то же самое. Я использовал Qt (v3 и v4) на других языках, и он нигде не близок, как приятно использовать: им нравится писать С++ на каком-то другом языке, а не как родные библиотеки. (Вам нужно передать синглы С++ как строки!)

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

Ответ 16

Разработка ядра Windows не поддерживает С++ (к сожалению).

Ответ 17

Вы можете прочитать забавную речь о том, почему Линус Торвальдс одобряет C здесь

Ответ 18

Исходный код на mac - objective-c. Родным кодом на ПК является c (window.h) или С++ (mfc). Обе эти среды позволят вам использовать c с небольшими изменениями или без изменений. Когда я хочу, чтобы библиотека кода была кросс-платформенной ansi c, кажется хорошим выбором.

Ответ 19

Я могу думать о нескольких причинах.

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

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

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

У вопросителя может быть устаревший вид кривой обучения С++. (При правильном приближении это проще, чем C. Большинство вводных книг, которые я видел, не подходят к нему правильно.)

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

Ответ 20

Если вы работаете в среде с двумя языками, вы можете использовать C для некоторых высокопроизводительных критически важных низкоуровневых функций и более функциональный/высокоуровневый язык, такой как С#/Java для бизнес-логики. Если для этих функций используется код С++, для JNI/неуправляемого кода требуется C-Wrappers, что делает вещи более сложными, чем использование C.

Ответ 21

Я использую С++ с программированием по двум причинам:

• vector и string, чтобы избавиться от управления памятью от меня.
• проверка строгого типа и отбрасывание, чтобы предупредить и/или поймать все неприятности, которые я пропустил бы иначе.

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

Ответ 22

Я думаю, что C более портативен. Я проработал около 5 лет назад, портируя код во многие разновидности unix (AIX, Irix, HPUX, Linux). Код C был легко переносится, но у нас были различные проблемы с переносом кода С++. Возможно, это были только незрелые среды разработки, но я бы скорее использовал C над С++ по этой причине...

Ответ 23

• C - простой язык, С++ - нет. Для многих людей С++ просто слишком сложна для полного освоения, см. http://en.wikipedia.org/wiki/C%2B%2B#Criticism.

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

• Сложность, подводные камни языка слишком сильно отвлекают, а иногда и вредят производительности. Вместо того, чтобы сосредоточиться на самой работе, я часто сталкивался с самим языком. Java/python - более продуктивные альтернативы.

• Отладка сломанного кода C обычно намного проще, чем отладка сломанного кода на С++.

• В отличие от Java/С#, стандартная библиотека С++ почти не выходит за рамки стандартной библиотеки C.

• Некоторые известные программисты, такие как Линус Торвальдс (Linux) и Ричард Столлман (Emacs), не любят С++.

Ответ 24

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

Ответ 25

Есть три причины, о которых я могу думать. Во-первых, C больше подходит для встроенных систем из-за небольшого размера своих двоичных файлов и более широкой доступности компиляторов C в любой системе. Вторая - переносимость: C - меньший язык, а код ANSI C будет компилироваться в любом месте. Легче сломать переносимость в С++. Последний - это сам язык. С++ сложнее, и это, безусловно, очень плохо разработанный язык. Охватывает Торвальдс выше. Вы также можете просмотреть часто задаваемые ответы С++ (http://yosefk.com/c++fqa/).

Ответ 26

Переносимость может быть проблемой. В отличие от ответа Gordon Carpenter-Thomp, я бы предположил, что это скорее поддержка времени исполнения различных версий libstdС++ в разных версиях linux/unix. См. эту ссылку для хорошей дискуссии об этом. Немного отрывок:

Код поддержки выполнения, используемый различными частями приложения на С++, должен быть совместимым. Если одной части программы требуется dynamic_cast или ловить объекты, предоставленные другим, обе части должны согласовать некоторые детали реализации: как найти vtables, как разматывать стек и т.д.

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

Ответ 27

Я могу следовать многим предложениям здесь в обоих направлениях. Но, в конце концов, это сводится к а) сопоставимые простые б) сопоставимый комплекс.

У меня нет идеи, если кто-то "изобрел" своего рода измерение сложности языка.

В масштабе от 0 до 10 я, вероятно, буду оценивать C на 2 или 3, тогда как С++ будет между 8-10. Я бы сказал, что С++ - один из самых сложных языков, но я не знаю, например, Ada, PL1 или тому подобное, поэтому, возможно, это не так сложно по сравнению с каким-либо другим языком.

С++ наследует всю сложность C, поэтому он не может быть ниже уровня сложности C.

Мне со своей стороны было бы гораздо удобнее использовать какой-то язык сценариев и C. Поэтому в конце нужно ответить на следующий вопрос. "Лучше ли лучше?"

Ответ 28

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

В С++ вы думаете об объектах и ​​о том, как они связаны друг с другом. В C вы думаете с точки зрения API. Это похоже на разницу между днем ​​и 17.

Плохая аналогия: если кто-то добавляет китайский на английский и называет его английским языком + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Ответ 29

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

Это важно при подключении новой функции или компонента к старой и запутанной системе.

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

Ответ 30

Ниже приведены все причины, по которым может быть полезно ограничить проект C:

• более быстрая компиляция, потому что язык намного проще
• требует меньше поддержки во время выполнения, что делает его более подходящим для низкоуровневых сред.
• гораздо проще взаимодействовать с другими языками
• поддерживает массивы с переменным размером в стеке
• легче читать ассемблерный код, потому что нет имени mangling
• позволяет легко скомпилировать код, созданный разными компиляторами, поскольку он является двоичным интерфейсом стандартного приложения de facto