Наша компания приобретет большой и очень сложный фрагмент исходного кода для спутниковой связи.
Он написан на C ++, и мы будем кодировать дополнения к нему, также на C ++, связывая наш код с приобретенным кодом в единый исполняемый модуль.
Необходимо ли использовать тот же компилятор и ту же версию компилятора, которая использовалась для разработки приобретенного кода?
Нужно ли использовать ту же версию C ++, что и купленный код? Если он не использует 2014, мы можем использовать некоторые его функции, но не в том случае, если могут возникнуть проблемы со смешиванием разных версий.
В теории, конечно, это не должно иметь значения, особенно языковая версия, но возможно, что разные версии компилятора будут генерировать разные объектные коды, что может привести к разнице во времени и т. Д.
Что мы должны знать?
Ответы:
По-разному.
Компиляторы генерируют код, ориентированный на ABI. Некоторые используют общий ABI (например, если я не ошибаюсь, и clang ++, и g ++ ориентированы на Itanium ABI), и вы должны - могут быть ошибки, мешающие вам сделать это - возможность использовать объектный код от обоих в одной программе (при условии, конечно, что вы используете версии, которые предназначены для одной и той же версии ABI). То же самое верно для версии компилятора: некоторые обращают больше внимания на то, чтобы сохранить одинаковый ABI между версиями, чем другие. Очевидно, что все они когда-нибудь нуждаются в изменении ABI, и они могут быть вынуждены сделать это несовместимым способом. И очевидно, что некоторые параметры, такие как выбор языкового стандарта, могут влиять на выбор ABI.
Тогда есть проблема стандартной библиотеки. Компиляторы (или разные версии одного и того же компилятора) могут использовать один и тот же ABI, но их стандартная библиотека может быть несовместима (и некоторые компиляторы, такие как clang ++, могут использоваться с несколькими стандартными библиотеками). Возможность заставить его работать, может зависеть от того, что используется в интерфейсе.
Другими словами, вы должны копать и находить информацию для конкретного случая, в котором вы находитесь. В качестве отправной точки и примера того, какую информацию вы должны искать, вот информация, предоставляемая libstdc ++ (библиотека, используемая g ++ и в какой-то конфигурации clang ++)
источник
Это не в основном технический вопрос. Это юридический вопрос о том, что вы пишете в своем контракте. Убедитесь, что поставщик программного обеспечения предоставляет вам гарантированную им версию для использования в вашей среде. В противном случае всегда будет определенный риск возникновения проблем с другим компилятором, версией компилятора или языковой версией.
Это особенно важно при покупке компонента или его частей в виде закрытого источника. Даже если ваш поставщик гарантирует, что вы можете использовать компонент с текущей средой компилятора, он гарантирует, что предоставит вам обновления, если вы хотите переключиться на более новую версию компилятора в будущем? Если у вас нет доступа к полному исходному коду, вам, вероятно, не повезет, если вы попытаетесь самостоятельно решить какие-либо проблемы с совместимостью. Вот почему вы должны не только купить программное обеспечение, но и подумать о заключении долгосрочного контракта на техническое обслуживание с вашим поставщиком.
источник
Звучит хорошо!
Говоря в общем, нет, это не нужно. Цель C ++ состоит в том, чтобы выступать в качестве абстракции над такими вещами, поэтому хорошо написанная программа на C ++ будет скомпилирована так же хорошо в вашей цепочке инструментов, как и в оригинальной, и полученная программа будет иметь тот же результат. Производительность может отличаться, потому что разные компиляторы хороши в разных вещах, но основное поведение программы не должно меняться.
Однако плохо написанное программное обеспечение может полагаться на поведение, зависящее от реализации, или даже на неопределенное поведение. Он может делать предположения о встроенных типах или об порядковости платформы. Даже хорошо написанное программное обеспечение может не иметь другого выбора, кроме как полагаться на нестандартные расширения, которые недоступны в выбранной вами цепочке инструментов, или это может быть связано с тем, что не было необходимости тратить время на добавление слоя переносимости в течение оригинальный проект.
В конечном итоге вам нужно будет спросить автора / поставщика, для чего написан исходный код. Если они утверждают, что они специально написаны для, скажем, Visual Studio 2015 и требуют функций Windows API, вам, вероятно, следует придерживаться этого. Но если они утверждают, что это переносимый стандарт C ++, используйте любой компилятор, который вам нравится. Убедитесь, что ваше соглашение о покупке включает в себя поддержку, чтобы вы могли получить бесплатную помощь, когда выясняется, что продавец лгал.
Наверное. Может быть.
C ++ 03 по большей части совместим с прямым интерфейсом, поэтому, если код C ++ 03, у вас вряд ли возникнут проблемы. (Хотя некоторые настройки могут потребоваться.)
Но функции, представленные в C ++ 11 и C ++ 14, не являются обратно совместимыми, поэтому, если поставщик использовал, скажем, C ++ 11 лямбда-выражения, и вы пытаетесь построить их код в компиляторе C ++ 03, который только что выиграл не работает
Абсолютно. Если код так сильно зависит от конкретной реализации, чтобы получить ожидаемые результаты, то поставщик должен нести ответственность и сообщить вам об этом. Поскольку мы живем в реальном мире, я рекомендую быть усердным и спросить их в первую очередь.
И я повторю то, что сказали другие: убедитесь, что у вас есть какое-то обращение за поддержкой, чтобы, если они искажают какой-либо из ответов на эти вопросы (умышленно или нет), вы не в конечном итоге взвалили на себя расходы.
источник
Вы не связываете код, вы связываете скомпилированные объектные файлы.
В этом случае да, использование разных компиляторов C ++ (или даже таких настроек, как сборки отладки / выпуска), или их разных версий, или разных (версий) стандартных библиотек при создании частей, которые будут взаимодействовать на двоичном уровне, с большой вероятностью может привести к поломке приложение, если части взаимодействуют друг с другом, используя более C API.
Такие функции, как контейнеры или исключения, обеспечивают один и тот же интерфейс, но на двоичном уровне могут быть реализованы многими различными несовместимыми способами.
Однако использование другого компилятора для компиляции всего кода является другой проблемой. Вопросы для рассмотрения:
Существует также риск того, что код может содержать части, которые приводят к неопределенному поведению. Может показаться, что они работают нормально при использовании одного компилятора, но загадочным образом не работают при использовании другого.
источник
Что ж, переключение компилятора может привести к некоторым проблемам; в настоящее время в моей компании мы используем Clang и MSVC, и у нас есть ошибка в одном компиляторе, который другой не помечает как таковой.
Это не обязательно, но, конечно, ваш компилятор должен поддерживать версию C ++, которую вы хотите использовать. C ++ гарантирует ретро-совместимость начиная со всех версий.
источник
Одна большая проблема при изменении компиляторов - неопределенное поведение: если код, который вы получаете, вызывает неопределенное поведение, то все возможно - включая то, что код работает просто отлично и проходит все свои тесты при использовании их компилятора, и ужасно неправильно работает с вашим компилятором.
Это возможно, но в этой ситуации вы также можете столкнуться с проблемами, если вы измените уровни оптимизации, используете следующую версию того же компилятора и так далее. Так что ничего нельзя избежать.
источник