Використання різних компіляторів C ++ та мовних версій при розробці одного виконуваного файлу

Наша компанія придбає великий і дуже складний фрагмент вихідного коду для супутникового зв'язку.

Він кодується в C ++, і ми будемо кодувати доповнення до нього, також в C ++, пов'язуючи наш код із придбаним кодом в єдиний виконуваний блок.

• Чи потрібно, щоб ми використовували той самий компілятор і ту саму версію компілятора, яку використовували для розробки придбаного коду?

• Чи потрібно, щоб ми використовували ту саму версію C ++, що і придбаний код? Якщо він не використовує 2014 рік, ми _might_ хочемо використовувати деякі його функції, але ні, якщо можуть виникнути проблеми зі змішуванням різних версій.

Теоретично, звичайно, це не повинно мати значення, особливо мовна версія, але можливо, що різні версії компілятора будуть генерувати різний об'єктний код, що потенційно може призвести до відмінностей у часі тощо.

Що ми маємо усвідомлювати?

Чи потрібно, щоб ми використовували той самий компілятор і ту саму версію компілятора, яку використовували для розробки придбаного коду?

Це залежить.

Компілятори генерують код, орієнтований на ABI. Деякі використовують спільний ABI (наприклад, якщо я не помиляюсь, цільова кланг ++ і g ++ називається Itanium ABI), і ви повинні - можливо, помилки заважають вам це робити - мати можливість використовувати об'єктний код від обох в одній програмі (якщо, звичайно, ви використовуєте версії, націлені на одну і ту ж версію ABI). Те саме стосується версії компілятора: деякі приділяють більше уваги, щоб зберегти той самий ABI між версією, ніж інші. Очевидно, що всі вони потребують колись зміни ABI, і вони можуть бути змушені робити це несумісним чином. І очевидно, деякі параметри, як вибір мовного стандарту, можуть мати вплив на вибір ABI.

Далі йде випуск стандартної бібліотеки. Самі компілятори (або різні версії одного і того ж компілятора) можуть використовувати один і той же ABI, і все ж їх стандартна бібліотека може бути несумісною (а деякі компілятори на зразок clang ++ можуть бути використані з декількома стандартними бібліотеками). Вміння змусити його працювати може залежати від того, що використовується в інтерфейсі.

Іншими словами, ви повинні викопати та знайти інформацію для конкретного випадку, в якому ви перебуваєте. Як вихідний приклад і приклад того, яку інформацію ви повинні шукати, ось інформація, надана libstdc ++ (бібліотека, яка використовується g ++ а в деякій конфігурації clang ++)

Чи потрібно, щоб ми використовували той самий компілятор і ту саму версію компілятора, яку використовували для розробки придбаного коду? Чи потрібно, щоб ми використовували ту саму версію C ++, що і придбаний код?

Це в основному не технічне питання. Це юридичне питання про те, що ви пишете у своєму контракті. Переконайтеся, що постачальник програмного забезпечення надає вам гарантовану ним версію , щоб бути корисною для вашого оточення. Інакше завжди буде певний ризик виникнути проблеми з іншим компілятором, версією компілятора або мовною версією.

Це особливо важливо, коли ви купуєте компонент або його частини в якості закритого джерела. Навіть якщо ваш постачальник гарантує, що ви можете використовувати компонент у поточному середовищі компілятора, він гарантує, що він надасть вам оновлення, якщо ви хочете в майбутньому перейти на нову версію компілятора? Якщо у вас немає доступу до повного вихідного коду, вам, мабуть, не пощастить самостійно вирішити будь-які проблеми сумісності. Ось чому вам слід не просто купувати програмне забезпечення, а й думати про довгостроковий договір технічного обслуговування з постачальником.

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

Звучить добре!

Чи потрібно, щоб ми використовували той самий компілятор і ту саму версію компілятора, яку використовували для розробки придбаного коду?

Якщо говорити взагалі, ні це не потрібно. Мета C ++ - діяти як абстракція над цими речами, тому добре написана програма C ++ складе так само добре на вашій інструментальній ланцюжку, як і в оригінальній авторській програмі, і отримана програма матиме такий самий результат. Продуктивність може відрізнятися, оскільки різні компілятори хороші в різних речах, але принципова поведінка програми не повинна змінюватися.

Однак, програмне забезпечення, що погано пишеться, може покладатися на поведінку, що залежить від впровадження, або навіть невизначену поведінку. Це може робити припущення про вбудовані типи або про витривалість платформи. Навіть добре написане програмне забезпечення може не мати іншого вибору, окрім як покластися на нестандартні розширення, які недоступні у вибраному ланцюжку інструментів, або це може зробити так, оскільки просто не потрібно було витрачати час на додавання шару переносимості протягом тривалості оригінальний проект.

Зрештою, вам потрібно буде запитати автора / продавця, для чого написаний вихідний код. Якщо вони стверджують, що це спеціально написано проти, скажімо, Visual Studio 2015 і вимагає функцій API Windows, ви, мабуть, повинні дотримуватися цього. Але якщо вони заявляють, що це портативний, стандартний C ++, то використовуйте будь-який компілятор, який вам подобається. Переконайтеся, що ваша угода про купівлю містить домовленість про підтримку, щоб ви могли отримати безкоштовну допомогу, коли виявиться, що продавець брехав.

Чи потрібно, щоб ми використовували ту саму версію C ++, що і придбаний код? Якщо він не використовує 2014 року, ми могли б хотіти використовувати деякі особливості цього, але якщо там можуть бути деякі проблеми з змішування різних версій.

Ймовірно. Можливо.

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

Але функції, введені в C ++ 11 і C ++ 14, не сумісні з зворотним зв'язком, тому якщо постачальник використовував, скажімо, C ++ 11 лямбда, і ви намагаєтеся створити їх код у компіляторі C ++ 03, який щойно виграв не працюю.

Теоретично, звичайно, це не повинно мати значення, особливо мовна версія, але можливо, що різні версії компілятора будуть генерувати різний об'єктний код, що потенційно може призвести до відмінностей у часі тощо.

Абсолютно. Якщо код так сильно покладається на конкретну реалізацію для отримання очікуваних результатів, то відповідальність та інформування вас про це залежить від продавця. Оскільки ми живемо в реальному світі, то рекомендую бути старанними і питати їх в першу чергу.

І я наголошу на тому, що сказали інші: переконайтеся, що у вас є якийсь спосіб звернення за підтримкою, щоб, якщо вони неправильно представили будь-яку відповідь на ці запитання (навмисно чи іншим чином), ви не закінчилися збивати отриману вартість.

Ви не пов'язуєте код, ви посилаєте компільовані файли об'єктів.

У цьому випадку так, використання різних компіляторів C ++ (або навіть налаштувань, таких як налагодження / випуск збірок), або різних їх версій, або різних (версій) стандартних бібліотек при побудові частин, які взаємодіють на бінарному рівні, велика ймовірність порушити додаток, якщо деталі спілкуються між собою за допомогою більш ніж API API.

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

Використання іншого компілятора для компіляції всього коду - це інша проблема. Питання, які слід врахувати:

• На яку платформу / архітектуру орієнтований код?
• Для якого стандарту було написано?
• Чи використовує якісь нестандартні функції компілятора?
• Чи містить код твердо кодовані певні припущення щодо платформи (як завжди, враховуючи, що покажчики займають 2 байти)?

Існує також ризик того, що код може містити частини, що призводять до невизначеної поведінки. Вони можуть здатися справними при використанні одного компілятора, але таємничими помилками при використанні іншого.

Чи потрібно, щоб ми використовували той самий компілятор і ту саму версію компілятора, яку використовували для розробки придбаного коду?

Ну, перемикання компілятора може призвести до деяких проблем; В даний час у моїй компанії ми використовуємо Clang та MSVC, і в одному компіляторі є помилка, яку інша не позначає як таку.

Чи потрібно, щоб ми використовували ту саму версію C ++, що і придбаний код? Якщо він не використовує 2014 року, ми могли б хотіти використовувати деякі особливості цього, але якщо там можуть бути деякі проблеми з змішування різних версій.

Це не обов'язково, але, звичайно, компілятор повинен підтримувати версію C ++, яку ви хочете використовувати. C ++ гарантують ретро сумісність, починаючи з усієї версії.

Однією з великих проблем при зміні компіляторів є невизначена поведінка: Якщо код, який ви отримуєте, посилається на невизначене поведінку, тоді все можливе - в тому числі, що код працює просто чудово і проходить усі їх тести при використанні їх компілятора, і зі своїм компілятором дуже страшно йде.

Це можливо, але в цій ситуації у вас можуть виникнути проблеми, якщо ви зміните рівні оптимізації, використовуйте наступну версію того ж компілятора тощо. Тож нічого не уникнути.