У меня дебаты с другом, и нам интересно, почему так много проектов с открытым исходным кодом решили пойти с C вместо С++. Такие проекты, как Apache, GTK, Gnome и многое другое, выбрали C, но почему не С++, так как это почти то же самое?
Мы точно ищем причины, которые привели бы к тому, что эти проекты (а не только те, что я перечислил, но все проекты C) отправились с C вместо С++. Темы могут быть производительность, простота программирования, отладка, тестирование, концепция и т.д.
C очень портативен, гораздо больше, чем С++ был 10 лет назад.
Кроме того, C очень укоренен в традиции Unix. Подробнее в разделе Искусство программирования Unix, о Unix и OO в общий и определенные языки в unix (включая C и С++).
Существует множество примеров счетчиков: все на основе Qt для одного.
Кроме того, в моей системе тестирования Debian:
[email protected]:~$ apt-cache rdepends libstdc++6|wc -l
4101
Так что 4101 пакетов в зависимости от базовой библиотеки С++. Для сравнения я получаю около 14,982 для libc6 или примерно 3,6 таких. Но это не так, если нет проектов на С++ в среде с открытым исходным кодом.
Изменить: Thinko с моей стороны: поскольку пакеты С++ также зависят от libc6, соотношение действительно
(14982 - 4101)/4101 = 2,65
поэтому в C реализовано примерно в 2 1/2 раза больше пакетов, чем в С++.
Замечательная книга Эрика Раймонда "Искусство программирования Unix" содержит некоторые размышления по этой проблеме (вся книга стоит прочитать в любой бумаги или бесплатных онлайн-изданий, я просто указываю на соответствующий раздел - Эрик был вовлечен в разработку и введение термина "open source", и он всегда стоит прочитать: -0).
Подводя итог этому разделу, Раймонд утверждает, что "языки OO демонстрируют некоторую тенденцию всасывать программистов в ловушку чрезмерного расслоения", а программисты Unix (и программисты с открытым исходным кодом) сопротивляются этой ловушке "толстого клея".
Позже в книге вы найдете некоторые соображения, особенно касающиеся С++, такие как "Возможно, что реализация С++ OO особенно проблематична, склонный". Согласны вы или нет, весь текст стоит прочитать (я вряд ли могу это сделать здесь!), И богатый библиографией, указывающий вам на многие другие соответствующие исследования и публикации.
Линус Торвальдс несколько раз высказывался по теме С++ - он использует C для git, и, конечно, ядро Linux в основном C:
Вы можете легко найти больше из них, и хотя в его характере, чтобы получить немного пламя об этих вещах, есть некоторые действительные точки.
Один из наиболее интересных (с тех пор, как я сижу, во всяком случае) - это наблюдение, что компиляторы и библиотеки С++ были (и в некоторой степени) намного более ошибочными, чем соответствующие компиляторы C. Это следует из соображений, учитывая относительные сложности двух языков.
Он немного пахнет синдромом "не придумал здесь" (NIH), но когда у вас есть база разработчиков ядра Linux, вы иногда можете позволить себе изобретать вещи "Правильный путь".
Многие проекты начались до того, как С++ был стандартизирован, поэтому C был очевидным выбором, и изменение позже было бы трудным. C был стандартизирован примерно за десять лет до С++ и был более переносимым еще дольше. Таким образом, в то время это было в значительной степени прагматичное решение, частично вдохновленное наследием Unix использования C для большинства кодов.
С++ - беспорядок. Это слишком сложный язык, настолько сложный, что лишь немногие люди могут сказать, что знают все биты. И меньше компиляторов, которые действительно соответствуют стандарту С++.
Поэтому я считаю, что причина проста и переносимость.
Если вы хотите более высокоуровневое и объектно-ориентированное программирование, то я думаю, что С++ просто конкурирует с другими, такими как Python. (Обратите внимание, что я запрограммировал на С++ несколько лет, он быстро и имеет некоторые функции на языках более высокого уровня, которые ускоряют разработку, без обид.)
В свое время я работал над несколькими проектами на С++, все из которых закончились слезами так или иначе. На самом фундаментальном уровне правда заключается в том, что людям нельзя доверять. Им нельзя доверять, чтобы писать хороший код, им нельзя доверять, чтобы отлаживать его, и им, конечно, нельзя доверять, чтобы понять это, когда они должны вернуться и изменить его снова через несколько недель/месяцев.
В C-коде не очень много странных вещей на С++, что затрудняет отладку (конструкторы/деструкторы, все, что происходит со статическими глобальными объектами во время cpp_initialize() и т.д.). Это просто облегчает работу при разработке и поддержании большого проекта.
Может быть, я луддит, но каждый раз, когда кто-то говорит "С++" вокруг меня, я дрожу.
Некоторые люди упомянули о переносимости, но в этот день переносимость С++ - это не большая проблема (она работает на любом GCC, который по сути является чем угодно). Однако переносимость - это больше, чем просто архитектура-архитектура или ОС-ОС. В случае С++ он включает компилятор-компилятор.
Давайте обсудим ABI или Application Binary Interface. Это в основном означает "как ваш код преобразуется в сборку". В C, когда вы пишете:
int dostuff(const char *src, char *dest);
Вы знаете, что вы делаете символ в своем объектном файле с именем _dostuff (глобальные имена 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 не) имя mangling, что означает, что эти две функции могут быть переведены на _dostuff_cp_cp и _dostuff_cp_cp_s (так что каждая версия функции, которая принимает различное количество аргументов, имеет другое имя).
Проблема с этим (и я считаю, что это огромная ошибка, хотя это не единственная проблема с кросс-компилятором в С++), что стандарт С++ оставил детали того, как манипулировать этими именами до компилятора. Поэтому, хотя один компилятор С++ может это сделать, другой может сделать _cp_cp_s_dostuff, а другой может сделать _dostuff_my_compiler_is_teh_coolest_char_ptr_char_ptr_size_t. Проблема усугубляется (всегда находите способ проникнуть этим словом во что-либо, что вы говорите или пишите) из-за того, что вам нужно манипулировать именами для более чем перегруженных функций - как насчет методов, пространств имен и перегрузки методов, так и перегрузки операторов и... (список можно продолжить). Существует только один стандартный способ убедиться, что ваше имя функции на самом деле является тем, что вы ожидаете от него на С++:
extern "C" int dostuff(const char *src, char *dest);
Многие приложения должны иметь (или, по крайней мере, находить это очень полезным) стандартный ABI, предоставленный C. Apache, например, не может быть почти как кросс-платформенный и легко расширяемый, если он был на С++ - вы 'd должен учитывать имя, которое обрабатывает конкретный компилятор (и конкретная версия компилятора - GCC несколько раз изменился в своей истории) или требует, чтобы все использовали один и тот же компилятор повсеместно - это означает, что каждый раз, когда вы обновляете свой С++ компилятор с обратной несовместимой схемой преобразования имен, вам нужно перекомпилировать все ваши программы на С++.
Это сообщение превратилось в нечто из монстра, но я думаю, что это иллюстрирует хороший момент, и я слишком устал, чтобы попытаться обрезать его.
Как кто-то, кто не любит С++, и в любой день выберет C, я могу хотя бы дать вам свои впечатления по этой теме. С++ имеет несколько атрибутов, которые делают его непривлекательным:
Тем не менее, С++ имеет преимущества поддержки объектов. Но когда дело доходит до этого, даже для больших проектов модульность может быть достигнута без объектов. Когда вы добавляете в том, что по существу каждый программист, который может внести код в любой проект, может запрограммировать C, кажется, что трудно сделать выбор, чтобы пойти с чем-нибудь еще, если вам нужно написать свой код, близкий к металу.
Все, что сказано, многие проекты перепрыгивают через С++ и переходят на такие языки, как Python, Java или Ruby, потому что они обеспечивают большую абстракцию и более быстрое развитие. Когда вы добавляете в свою способность поддерживать компиляцию/загрузку из C-кода для частей, требующих удара производительности, С++ теряет то, что могло бы иметь.
Если вы посмотрите на недавние проекты с открытым исходным кодом, вы увидите, что многие из них используют С++. Например, KDE имеет все свои подпроекты в С++. Но для проектов, которые начались десять лет назад, это было рискованное решение. C был более стандартизирован в то время как формально, так и на практике (реализации компилятора). Кроме того, С++ зависит от большей производительности и отсутствия хороших библиотек в то время. Вы знаете, что личное предпочтение играет большую роль в таком решении, и в то время рабочая сила C в проектах UNIX/Linux была намного больше, чем С++, поэтому вероятность того, что начальный разработчик (ов) для нового проекта был более удобен с C было больше. Кроме того, любой проект, который должен выставить API, будет делать это на C (чтобы избежать проблем с ABI), поэтому это будет еще один аргумент в пользу C. И, наконец, до того, как интеллектуальные указатели стали популярными, было гораздо опаснее программировать на С++. Вам потребуются более опытные программисты, и им нужно будет быть чрезмерно осторожными. Хотя C имеет те же проблемы, его более простые структуры данных легче отлаживать с помощью инструментов/библиотек для проверки границ.
Также подумайте, что С++ - это опция только для высокоуровневого кода (настольные приложения и т.п.). Ядро, драйверы и т.д. Не являются жизнеспособными кандидатами на разработку С++. В С++ слишком много "под капотом" (цепочки конструктора/деструктора, таблица виртуальных методов и т.д.), И в таких проектах вам нужно убедиться, что итоговый код машины/сборки не будет иметь никаких сюрпризов и не зависит от времени выполнения поддержка библиотеки для работы.
Одним из важных аспектов в дополнение к другим, которые, несомненно, будут упомянуты, является то, что C легче взаимодействовать с другими языками, поэтому в случае библиотеки, которая должна быть широко полезна, C может быть выбрана даже сегодня для этой цели.
Для получения примеров, с которыми я знаком, набор инструментов GTK + (в C) имеет надежные привязки OCaml, а Qt и Cocoa (соответственно в С++ и Objective C) имеют только доказательство концепций для таких привязок. Я считаю, что трудность для интерфейса языков, отличных от C с OCaml, является частью причины.
Одна из причин может заключаться в том, что стандарты кодирования GNU специально просят вас использовать C. Еще одна причина, по которой я могу думать, заключается в том, что бесплатное программное обеспечение инструменты работают лучше с C, чем на С++. Например, отступ GNU не делает С++, а также C, или etags не анализирует С++, а также анализирует C.
Я могу перечислить еще несколько причин.
Прежде всего, некоторые из самых больших проектов с открытым исходным кодом написаны на С++: Open Office, Firefox, Chrome, MySQL,...
Сказав это, есть также много больших проектов, написанных на C. Причины меняются: они, возможно, были начаты, когда С++ еще не стандартизировался, или авторы/были более удобны с C, или они надеялись, что более легкое обучение кривая для C привлечет больше участников.
Если правильно реализовано C очень быстро и очень портативно, и компиляторы там
С++ отличается для каждого доступного компилятора, библиотеки не согласны, стандарты не соответствуют.
Вы можете прочитать Dov Bulka, чтобы узнать, что не делать в cpp, вы можете прочитать tesseract ocr в коде Google, вы можете прочитать много вещей - большинство из которых зависит от того, где вы должны определить, какой лингвистический код превосходит. Где вы прочитали, что c имеет больше исходного кода в open source, чем cpp? Ну, конечно, вы читали это на форуме c. Это где. Перейдите к другому языку программирования. Сделайте тот же поиск, вы обнаружите, что этот код имеет более открытый исходный код.