2012-01-16 8 views
5

Nella mia azienda, siamo passati di recente da VC9 a VC10.Il mix dei runtime è una soluzione praticabile?

Abbiamo migrato i nostri progetti, ma poi il responsabile ci ha detto che avremmo dovuto conservare alcune DLL comuni di base compilate con VC9 sulle nostre macchine di produzione per qualche tempo.

Queste DLL fanno uso di strutture personalizzate, alcune delle quali contengono std::vector, std::map e così via. Ora, ho notato che le dimensioni dei contenitori standard sono cambiate: alcune sono diventate più grandi, altre sono diventate più piccole. Di conseguenza, anche le dimensioni delle nostre strutture personalizzate sono cambiate.

Per risolvere i problemi causati dalla modifica delle dimensioni, un mio collega ha pensato di aumentare artificialmente le dimensioni delle nostre strutture per consentire di compensare le modifiche delle dimensioni dei membri futuri in modo che le strutture mantengano le stesse dimensioni, indipendentemente dal tempo di esecuzione. utilizzare, impedendo il danneggiamento dello stack durante le chiamate di funzione.

Personalmente, ritengo che questa "soluzione" sia orribile perché mentre le dimensioni contano, così pure il layout delle strutture. Per me, aumentare l'impronta di memoria di tutte le strutture per risolvere i problemi organizzativi sembra davvero sbagliato.

Per farla breve, la mia domanda è: è anche possibile utilizzare contemporaneamente due diversi runtime (usando il trucco descritto o qualsiasi altro trucco) mentre si usano tipi non C nei prototipi di funzione? Hai qualche buona/cattiva esperienza riguardo una situazione simile?

risposta

9

STL non ha mai garantito la compatibilità binaria tra le diverse versioni principali. Pertanto, se si dispone di DLL con classi STL nell'interfaccia, è necessario utilizzare lo stesso compilatore e lo stesso aroma del CRT per il client della DLL e della DLL stessa.

Se si vuole costruire DLL che può essere utilizzato in modo sicuro con diverse versioni del compilatore, avete alcune opzioni, come:

  1. esporre una pura interfaccia C (la DLL può essere scritto in C++, ma l'interfaccia deve essere pura C e le eccezioni C++ non possono attraversare i confini della DLL).
  2. Esporre interfacce astratte all'interfaccia DLL, come spiegato in questo article.
  3. Utilizzare COM.
+0

'1.' non è un'opzione, ma' 2.' potrebbe funzionare davvero bene. Grazie mille per l'articolo collegato. – ereOn

+0

@ereOn: prego. –

1

Dovresti assicurarti che tutto ciò che ha bisogno di usare quelle vecchie librerie sia stato collegato a loro e compilato con i file di intestazione forniti con quella versione di quelle librerie. Non c'è altro modo per farlo, perché C++ deve essere in grado di vedere i file di intestazione per sapere come indirizzare qualsiasi struttura dati.

Ho l'impressione dalla tua domanda che ti collegherai con alcune librerie che sono a loro volta compilate e collegate al runtime VC9, nel qual caso potrebbe essere possibile collegare il resto del codice con VC10, basta che le librerie non espongano nessuno dei tipi di libreria VC9 nelle loro interfacce. Dico 'potrebbe essere', questa è un'area piena di insidie ​​e trappole e in generale direi che dovresti usare lo stesso runtime per tutto il tempo possibile. L'ultima cosa di cui hai bisogno è che il compilatore si confonda su quale versione di std :: vector stai parlando (e puoi garantire che i programmatori si confondano anche se puoi convincere il compilatore e il linker a capirlo) .

È più difficile, ma è più semplice attenersi semplicemente al vecchio runtime fino a quando non è più necessario su macchine di destinazione.

+0

Grazie per la risposta. Abbiamo già migrato tutti i nostri codici base in VC10 e, proprio come se la situazione non fosse già schifosa, il nostro controllo della versione sorgente (VSS) rende molto difficile, se non impossibile, riportare queste modifiche, quindi tornare a VC9 è non è più un'opzione :( – ereOn

+0

Questa non è una funzionalità prevista di un sistema di controllo delle versioni. Sento per te, penso che la nostra soluzione di controllo delle versioni qui sarebbe ancora peggio, è troppo intraprendente per fare cose come il ripristino, la ramificazione o non chiudendo globalmente i file al check-out –

+1

Per "impresa" si intende "vecchio e appena funzionante", vero? VSS è davvero terribile, lo capisco. Sembra che tu sia in una situazione spiacevole. –

1

L'ho già fatto prima, il riempimento delle strutture è stato simile. Sì, puoi usare due diversi runtime e dovrebbe funzionare bene fintanto che gli ABI sono gli stessi: qui è dove colpisci il muro quando le strutture iniziano a cambiare dimensioni, e spostando C++ (dove l'ABI è dappertutto) I confini della DLL sono davvero, davvero disordinati. Soprattutto dato che VC10 ha alcune modifiche in previsione di C++ 11. Io uso C per le DLL, interamente per le garanzie che mi fornisce in termini di compatibilità binaria.

È difficile per me offrire un caso specifico in cui le cose lo mangeranno davvero, ma lascia che te lo metta in questo modo: sono gli insetti che non prevedi che ti prenderanno, e questo è un vero nido di calabroni .

Problemi correlati