Почему это важно для компиляции кода C/С++ на разных компиляторах?

Ответ 1

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

Итак, зачем пытаться соответствовать стандарту или сделать ваш код приемлемым для нескольких компиляторов, а не просто записывать любой gcc (или ваш другой любимый компилятор)?

• Вероятно, в 2015 году gcc примет довольно иной язык, чем сегодня. Вы бы предпочли не переписывать свой старый код.

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

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

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

Из всех этих аргументов это аргумент инструмента, который я считаю наиболее убедительным. Люди забывают, что есть другие вещи, которые можно сделать с исходным кодом, кроме того, что просто скомпилировать его и запустить. На другом языке Haskell инструменты для анализа и рефакторинга сильно отставали от компиляторов, но люди, которые придерживались стандарта Haskell 98, имеют доступ к гораздо большему количеству инструментов. Аналогичная ситуация, скорее всего, для C: если я собираюсь приложить усилия к созданию инструмента, я собираюсь основывать его на стандарте с продолжительностью жизни 10 лет или около того, а не на версии gcc, которая может измениться до мой инструмент завершен.

Тем не менее, многие люди могут позволить себе полностью игнорировать переносимость. Например, в 1995 году я изо всех сил старался убедить Линуса Торвальдса в возможности компиляции Linux с любым компилятором ANSI C, а не только с gcc. У Линуса не было никакого интереса, и я подозреваю, что он пришел к выводу, что в нем нет ничего для него или его проекта. И он был прав. С Linux компиляция только с gcc была большой потерей для исследователей компилятора, но без потерь для Linux. "Инструмент-аргумент" не выполнялся для Linux, потому что Linux стал настолько дико популярным; люди, занимающиеся анализом и поиском ошибок для программ на C, были готовы работать с gcc, потому что работа на Linux позволила бы их работе иметь большое влияние. Поэтому, если вы можете рассчитывать на то, что ваш проект станет диким, как Linux или Mosaic/Netscape, вы можете позволить себе игнорировать стандарты: -)

Ответ 2

Некоторые причины из головы:

1) Чтобы избежать блокировки с одним поставщиком компилятора (с открытым исходным кодом или нет).

2) Компиляция кода с разными компиляторами, скорее всего, обнаружит больше ошибок: предупреждения разные, а разные компиляторы поддерживают стандарт в разной степени.

Ответ 3

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

Хорошо компилироваться под компилятором Intel, потому что он часто компилирует более быстрый код.

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

В общем, хорошо держать ваши варианты открытыми, потому что нет ни одного компилятора, который бы соответствовал бы всем потребностям. GCC является хорошим компилятором и отлично подходит для большинства целей, но вам иногда нужно что-то еще.

И даже если вы обычно собираете компиляцию в GCC, убедитесь, что ваш код компилируется под другими компиляторами, также, вероятно, поможет найти проблемы, которые могут помешать вашему коду работать с прошлыми и будущими версиями GCC, например, если есть что-то, что GCC сейчас менее жестко, но позже добавляет проверки, другой компилятор может заблаговременно поймать, помогая вам очистить свой код. Я нашел это полезным в обратном случае, когда GCC обнаружил больше потенциальных проблем с предупреждениями, чем MSVC (MSVC - единственный компилятор, который нам нужно было поддерживать, поскольку мы только отправляли в Windows, но мы сделали частичный порт для Mac под GCC в наше свободное время), что позволило мне создать более чистый код, чем в противном случае.

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

Это очень распространено для приложений (особенно с открытым исходным кодом), которые другие разработчики хотели бы использовать для разных компиляторов. Некоторые предпочитают использовать Visual Studio с MS Compiler для целей разработки. Некоторые предпочли бы использовать компилятор Intel для заявленных преимуществ производительности и т.д.

Ответ 7

Итак, вот почему я могу думать о

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

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

Ответ 8

Как правило, это причины, по которым я нашел:

• кросс-платформенный (windows, linux, mac)
• разные разработчики, занимающиеся разработкой на разных ОС (хотя и не оптимальные, это происходит - тестирование обычно происходит только на целевой платформе).
• Компании-компиляторы выходят из бизнеса - или прекращают разработку на этом языке. Если вы знаете, что ваша программа хорошо компилируется/работает с использованием другого компилятора, вы указали свою ставку.

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

Ответ 9

Это один из вопросов "Это зависит". Для открытого кода хорошо переноситься на несколько компиляторов. После того, как все люди в разных средах создают код, это своего рода точка.

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

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

for (int ii = 0; ii < n; ++ii) { /* some code */ }
for (int ii = 0; ii < y; ++ii) { /* some other code */ }

В то время как новый компилятор жаловался, что ii был объявлен дважды, поэтому нам пришлось пройти весь наш код и объявить переменные цикла перед циклом, чтобы переключиться.

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

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

Ответ 10

Несколько проектов используют GCC/g++ как "повседневный" компилятор для нормального использования, но каждый так часто проверяет, чтобы их код соответствовал стандартам с помощью компилятор Comeau C/С++. Их сайт выглядит как кошмар, а компилятор не является бесплатным, но он известен как, возможно, самый совместимый со стандартами компилятор и предупреждает вас о том, что многие компиляторы молча принимают или явно разрешают в качестве нестандартного расширения (да, я "Я смотрю на вас, г-н I-don -t-mind-and-fact-active-support-your-effort-to-do-pointer-arithmetic-on-void-pointers-GCC).

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

(Отказ от ответственности: у меня нет Комо, и я не планирую его получать, и не могу получить его, потому что я на OS X. Я делаю C, а не С++, поэтому я действительно могу знать все язык, а средний компилятор C намного ближе к стандарту C, чем средний компилятор С++, к стандарту С++, поэтому для меня это не проблема. Просто захотелось включить это здесь, потому что это стало выглядеть как объявление для Comeau. Это следует рассматривать как объявление для компиляции со многими разными компиляторами.)

Ответ 11

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

Ответ 12

Я не думаю, что кто-то упомянул об этом до сих пор, но другая причина может быть доступ к определенным особенностям платформы. Многие поставщики операционной системы имеют специальные версии GCC или даже свой собственный дом (или лицензированных и измененных) компиляторов. Поэтому, если вы хотите, чтобы ваш код работал на нескольких платформах, вам может потребоваться выбрать правильный компилятор на каждой платформе. Будь то встроенная система, MacOS, Windows и т.д.

Кроме того, скорость может быть проблемой (как скоростью компиляции, так и скоростью выполнения). Вернувшись в PPC-дни, GCC издал заведомо медленный код на процессорах PowerPC, поэтому Apple поставила кучу инженеров на GCC, чтобы улучшить это (GCC был очень новым для Mac, а все остальные платформы PowerPC были небольшими). Платформы, которые используются меньше, могут быть оптимизированы меньше в GCC, поэтому использование другого компилятора, написанного для этой платформы, может быть быстрее.

Но в качестве окончательного резюме: Несмотря на то, что в компиляторах есть идеальная ценность для компиляции, на практике это в основном интересно для кросс-платформенного программного обеспечения (и программного обеспечения с открытым исходным кодом, поскольку оно часто становится кросс-платформенным довольно быстро, и вкладчикам легче, если они могут использовать свой компилятор выбора вместо того, чтобы изучать новый). Если вам требуется только на одной платформе, доставка и обслуживание обычно важнее, чем инвестиции в создание нескольких компиляторов, если вы только выпускаете сборки, сделанные одним из них. Тем не менее, вы захотите четко зафиксировать любые отклонения от стандарта (например, GCC-isms), чтобы упростить работу по переносу, если вам когда-либо понадобится это делать.

Ответ 13

Оба компилятора Intel и llvm быстрее, чем gcc. Настоящими причинами использования gcc являются

• Бесконечная аппаратная поддержка (ни в одном компиляторе вы не можете скомпилировать кодекс боя lego в своей старой DEC).

• это дешево

• лучший оптимизатор spagety в бизнесе.