Utilizzo di diversi compilatori C ++ e versioni linguistiche durante lo sviluppo di un singolo eseguibile

Is it necessary that we use the same compiler and same compiler version as was used to develop the purchased code?

Dipende.

I compilatori generano codice di targeting per un ABI. Alcuni usano un ABI comune (ad esempio, se non sbaglio, sia clang ++ che g ++ targetizzati a Itanium ABI) e dovresti - potrebbero esserci dei bachi che ti impediscono di farlo - essere in grado di usare il codice oggetto da entrambi in uno stesso programma (presupponendo ovviamente che si stiano utilizzando versioni che hanno come target la stessa versione dell'ABI). Lo stesso vale per la versione del compilatore: alcuni prestano più attenzione a mantenere lo stesso ABI tra una versione e l'altra. Ovviamente, tutti hanno bisogno di un cambiamento ABI e potrebbero essere costretti a farlo in un modo non compatibile. E ovviamente, alcune impostazioni come la scelta di uno standard linguistico potrebbero influenzare la scelta dell'ABI.

Poi c'è il problema della libreria standard. I compilatori stessi (o versioni diverse dello stesso compilatore) possono usare lo stesso ABI, e tuttavia la loro libreria standard potrebbe essere incompatibile (e alcuni compilatori come clang ++ potrebbero essere utilizzabili con diverse librerie standard). Essere in grado di farlo funzionare può dipendere da ciò che viene utilizzato nell'interfaccia.

In altre parole, devi scavare e trovare le informazioni per il caso specifico in cui ti trovi. Come punto di partenza e un esempio del tipo di informazioni che dovresti cercare, qui è l'informazione fornita da libstdc ++ (la libreria usata da g ++ e in qualche configurazione da clang ++)

Is it necessary that we use the same compiler and same compiler version as was used to develop the purchased code? Is it necessary that we use the same version of C++ as the purchased code?

Questa non è principalmente una questione tecnica. È una domanda legale su ciò che scrivi nel tuo contratto. Assicurati che il fornitore del software ti fornisca una versione da lui utilizzabile nel tuo ambiente. Altrimenti, ci sarà sempre un certo rischio di incorrere in problemi con un compilatore, una versione del compilatore o una versione linguistica diversi.

Questo è particolarmente importante quando acquisti il componente o parti di esso come closed source. Anche se il fornitore ti garantisce di poter utilizzare il componente con l'attuale ambiente del compilatore, garantisce che ti fornirà aggiornamenti se desideri passare a una versione più recente del compilatore in futuro? Se non si ha accesso al codice sorgente completo, probabilmente non si avrà molta fortuna nel tentativo di risolvere autonomamente eventuali problemi di compatibilità. Questo è il motivo per cui non dovresti semplicemente acquistare il software, ma anche pensare a un contratto di manutenzione a lungo termine con il tuo fornitore.

Our company will purchase a large and very complex piece of source code for satellite communications. It is coded in C++ and we will code additions to it, also in C++, linking our code with the purchased code into a single executable unit.

Sembra buono!

Is it necessary that we use the same compiler and same compiler version as was used to develop the purchased code?

Parlando in generale, no non è necessario. Lo scopo di C ++ è di agire come un'astrazione su questo tipo di cose, quindi un programma C ++ ben scritto si compilerà altrettanto bene sulla tua toolchain come ha fatto sull'autore originale, e il programma risultante avrà lo stesso risultato. Le prestazioni possono variare, perché diversi compilatori sono validi per cose diverse, ma il comportamento fondamentale del programma non dovrebbe cambiare.

Tuttavia, il software scritto male può basarsi su un comportamento specifico dell'implementazione o anche su un comportamento non definito. Può fare supposizioni sui tipi built-in o sulla endianità della piattaforma. Anche il software ben scritto può non avere altra scelta che fare affidamento su estensioni non standard che non sono disponibili sulla toolchain prescelta, o può farlo perché semplicemente non c'era bisogno di dedicare tempo all'aggiunta di uno strato di portabilità entro la durata di il progetto originale.

In definitiva, dovrai chiedere all'autore / venditore quale sia il codice sorgente per cui è stato scritto. Se affermano che è specificamente scritto contro, ad esempio, Visual Studio 2015 e richiede le funzionalità dell'API di Windows, si dovrebbe probabilmente attenersi a ciò. Ma se affermano che è portatile, standard C ++, allora usa qualsiasi compilatore che ti piace. Assicurati che il tuo contratto di acquisto includa un accordo di assistenza in modo che tu possa ricevere assistenza gratuita quando risulta che il venditore stava mentendo.

Is it necessary that we use the same version of C++ as the purchased code? If it is not using 2014, we might want to use some features of it, but not if there might be some problems with mixing different versions.

Probabilmente. Forse.

C ++ 03 è in avanti compatibile per la maggior parte quindi, se il codice è C ++ 03, allora è improbabile che abbia un problema. (Anche se potrebbero essere necessarie alcune modifiche.)

Ma le funzionalità introdotte in C ++ 11 e C ++ 14 non sono compatibili con le versioni precedenti, quindi se il fornitore usa, ad esempio, C ++ 11 lambdas e si tenta di creare il proprio codice in un compilatore C ++ 03, che semplicemente non funzionerà.

In theory, of course, it ought not to matter, especially the language version, but it is conceivable that different versions of the compiler will generate different object code, potentially leading to timing differences, etc.

Assolutamente. Se il codice si basa tanto su una specifica implementazione al fine di ottenere risultati attesi, allora spetta al venditore essere responsabile e informarlo. Dato che viviamo nel mondo reale, raccomando di essere diligente e di chiederli prima.

E farò eco a quello che hanno detto gli altri: assicurati di avere una sorta di ricorso per il supporto, in modo che se travisano una qualsiasi delle risposte a queste domande (intenzionalmente o meno) non finisci con il costo risultante .

Non colleghi il codice, colleghi i file oggetto compilati.

In questo caso sì, usando diversi compilatori C ++ (o anche impostazioni come le build di debug / release), o versioni diverse di esse, o diverse (versioni di) librerie standard quando si costruiscono parti che interagiranno a livello binario è altamente probabile per rompere l'applicazione se le parti comunicano tra loro utilizzando più di API C.

Funzioni come contenitori o eccezioni forniscono la stessa interfaccia ma, a livello binario, possono essere implementate in molti modi diversi e incompatibili.

Utilizzare un compilatore diverso per compilare l'intero codice è comunque un problema diverso. Domande da considerare:

• Quale piattaforma / architettura ha il codice target?
• Per quale standard è stato scritto?
• Utilizza qualche caratteristica del compilatore non standard?
• Il codice contiene presupposti specifici della piattaforma hard-coded (come sempre considerando che i puntatori occupano 2 byte)?

Esiste anche il rischio che il codice possa contenere parti che comportano un comportamento non definito. Questi potrebbero sembrare funzionare bene quando si utilizza un compilatore, ma falliscono in modi misteriosi quando si utilizza uno diverso.

Is it necessary that we use the same compiler and same compiler version as was used to develop the purchased code?

Bene, cambiare compilatore può portare ad alcuni problemi; attualmente nella mia azienda, usiamo Clang e MSVC, e abbiamo un errore in un compilatore che l'altro non contrassegna come tale.

Is it necessary that we use the same version of C++ as the purchased code? If it is not using 2014, we might want to use some features of it, but not if there might be some problems with mixing different versions.

Non è necessario, ma ovviamente il compilatore dovrebbe supportare la versione C ++ che si desidera utilizzare. C ++ garantisce la retro compatibilità a partire da tutte le versioni.

Un grosso problema quando si cambiano i compilatori è un comportamento indefinito: se il codice che si riceve invoca un comportamento indefinito, allora tutto è possibile - incluso il codice funziona bene e passa tutti i test quando si usa il compilatore, e si sbaglia terribilmente il tuo compilatore.

È possibile, ma in quella situazione potresti anche incontrare dei problemi se cambi i livelli di ottimizzazione, usi la prossima versione dello stesso compilatore e così via. Quindi niente che puoi evitare.