Почему большинство самых больших проектов с открытым исходным кодом в C? [закрытый]

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

Чтобы взять примеры, с которыми я знаком, инструментарий GTK + (в C) имеет надежные привязки OCaml, в то время как Qt и Cocoa (соответственно в C ++ и Objective C) имеют только проверки концепций для таких привязок. Я считаю, что сложность интерфейса с другими языками, кроме C, с OCaml является одной из причин.

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

• Сложные объекты. C ++ обладает огромной способностью ускорять ОО, что делает язык очень сложным.
• Нестандартный синтаксис. Даже сегодня большинство компиляторов C ++ поддерживают причуды, которые затрудняют обеспечение успешной и правильной компиляции между компиляторами.
• Нестандартные библиотеки. По сравнению с библиотеками C библиотеки C ++ не так стандартизированы в разных системах. Мне пришлось столкнуться с проблемами Make, связанными с этим, прежде чем я скажу вам, что работа с C - это большая экономия времени.

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

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

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

Так что я думаю, что причина в простоте и портативности.

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

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

Давайте обсудим ABI, или двоичный интерфейс приложения. Это в основном означает «как ваш код переводится в сборку». В C, когда вы пишете:

int dostuff(const char *src, char *dest);

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

int dostuff(const char *src, char *dest);
int dostuff(const char *src, char *dest, size_t len);

Или даже:

int dostuff(std::string src, std::string dest);

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

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

extern "C" int dostuff(const char *src, char *dest);

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

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

Вы можете прочитать Дов Булка, чтобы узнать, чего нельзя делать в cpp, вы можете прочитать tesseract ocr в коде Google, вы можете прочитать множество вещей - большинство из которых зависит от того, где вы находитесь, чтобы определить, какой код лингвистический лучше. Где вы читали, что c имеет больше исходного кода в открытом доступе, чем cpp? Вы, конечно, читали об этом на форуме ac. Вот где. Перейти к другому языку программирования. Проделайте тот же поиск, вы обнаружите, что этот код имеет более открытый исходный код.

Прежде всего, некоторые из крупнейших проектов с открытым исходным кодом написаны на C ++: Open Office, Firefox, Chrome, MySQL, ...

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

I can list a couple more reasons

1. C code produces more compact object code. Try to compile 'Hello World' as C and C++ program and compare the size of the executable. May not be too relevant today but definitely was a factor 10+ years ago
2. It is much easier to use dynamic linking with C programs. Most of the C++ libraries still expose entry points through C interface. So instead of writing a bridge between C++ and C why not to program the whole thing in C?

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

Линус Торвальдс несколько раз высказывался по теме C ++ - он использует C для git, и, конечно же, ядро ​​Linux - это в основном C:

• на C ++ и git ( предупреждение: сначала наденьте огнестойкие)
• интервью с Линусом в 1998 г.

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

Это немного пахнет синдромом «изобретено не здесь» (NIH), но когда у вас есть вся база разработчиков ядра Linux,

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

Есть множество примеров счетчиков: все основано на Qt за одного.

Также в моей системе тестирования Debian:

edd@ron:~$ apt-cache rdepends libstdc++6|wc -l
4101

Итак, это 4101 пакет, зависящий от базовой библиотеки C ++. Для сравнения, я получил около 14 982 для libc6, что примерно на 3,6 больше. Но это не так, если в стране с открытым исходным кодом нет проектов C ++.

Edit: Thinko с моей стороны: поскольку пакеты C ++ также зависят от libc6, соотношение действительно равно

(14982 - 4101 ) / 4101 = 2,65

, поэтому на C реализовано примерно в 2 1/2 раза больше пакетов, чем на C ++.

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

Код C не содержит много странных вещей в C ++, которые затрудняют отладку (конструкторы / деструкторы, все, что происходит со статическими глобальными объектами во время cpp_initialize () и т. Д.). Это просто упрощает работу при разработке и сопровождении большого проекта.

Может быть, я луддит, но каждый раз, когда кто-то говорит «C ++» вокруг меня, меня охватывает дрожь.

В замечательной книге Эрика Раймонда «Искусство программирования в Unix» есть некоторые размышления по этому вопросу (всю книгу стоит прочитать в бумажном или бесплатном онлайн-издании, Я просто указываю на соответствующий раздел - Эрик участвовал в создании и введении термина «открытый исходный код», и его всегда стоит прочитать; -0).

Подводя итог этому разделу, Раймонд утверждает, что «OO языки демонстрируют некоторую тенденцию втягивать программистов в ловушку чрезмерного многоуровневого размещения », и программисты Unix (и, соответственно, программисты с открытым исходным кодом) сопротивляются этой ловушке« толстого клея ».

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

Если вы посмотрите на недавние проекты с открытым исходным кодом, вы увидите, что многие из них используют C ++. KDE, например, имеет все свои подпроекты на C ++. Но для проектов, начатых десять лет назад, это было рискованное решение. В то время C был более стандартизован как формально, так и на практике (реализации компилятора). Также C ++ зависит от большей среды выполнения и в то время не хватает хороших библиотек. Вы знаете, что личные предпочтения играют большую роль в таком решении, и в то время рабочая сила C в проектах UNIX / Linux была намного больше, чем C ++, поэтому вероятность того, что первоначальный разработчик (и) для нового проекта был более доволен C было больше. Кроме того, любой проект, которому необходимо предоставить API, сделает это на C (чтобы избежать проблем с ABI), И, наконец, до того, как умные указатели стали популярными, программировать на C ++ было гораздо опаснее. Вам понадобятся более опытные программисты, и они должны будут проявлять чрезмерную осторожность. Хотя C имеет те же проблемы, его более простые структуры данных легче отлаживать с помощью инструментов / библиотек проверки границ.

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

Если правильно реализован, C очень быстрый и очень переносимый, а компиляторы есть

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