È possibile collegare una libreria C ++ 11 compilata (lib, dll, ecc.) Nei compilatori C ++ più vecchi?

12

I compilatori C ++ più vecchi (ad es. VS2008 e gcc3.4) potrebbero collegarsi con librerie esterne scritte in C ++ 11?

Il mio pensiero è che i file .lib C ++ 11 siano solo byte code in questa fase, e non dovrebbe disturbare i compilatori più vecchi come è stato generato, purché sia in qualche modo risolvibile e richiamabile.

Sto sviluppando una piccola libreria la cui API dovrebbe ancora supportare gli utenti C ++ 03. Quindi, guardando al futuro, mi chiedo se sia ok implementare la mia libreria usando utili funzioni come std::unique_ptre simili, o devo semplicemente attenermi boost::?

c++ c++11

— Konafa
fonte

10

A condizione che la tua libreria utilizzi solo C ++ 11 nella sua implementazione e non esponga pubblicamente strutture o tipi di C ++ 11, e specialmente se usi un collegamento statico, allora sì, questo è possibile e persino standard.

Considera il caso comune in cui una libreria espone un'interfaccia di livello C (utilizzabile dalla più ampia varietà di client) ma che è implementata internamente in C ++. I client che si collegano a tale libreria devono solo preoccuparsi dell'API binaria pubblica (funzioni esportate), che avrai vincolato a essere C / C ++ legacy per la massima compatibilità. Un programma Java può collegarsi ad API di livello C che sono implementate internamente in C ++. Ciò non significa che Java debba "supportare C ++". Allo stesso modo, un client C / C ++ vecchio stile può collegarsi a un'API di livello C o C ++ che utilizza internamente alcune versioni più all'avanguardia delle librerie C ++ o di altre librerie. Due cose separate: cosa è necessario per collegarsi all'interfaccia della biblioteca e ciò a cui la biblioteca stessa si collega (o inserisce staticamente) internamente.

Semplicemente non esponi i client della tua libreria alle dipendenze della tua implementazione.

Se riesci a collegare staticamente le tue dipendenze (C ++ 11 o qualsiasi altra cosa) alla tua libreria, questo è pulito e autonomo. La libreria è una vera scatola nera: nient'altro che bytecode. Ma anche se la tua libreria si collega alle tue dipendenze tramite un collegamento "implicito dinamico" (da non confondere con il tipo di esplicito LoadLibrary / GetProcAddress e metodi simili su * nix e OS X), i client più vecchi dovrebbero comunque essere in grado di collegarsi a quello di quella libreria interfaccia pubblica, anche se non potevano collegarsi alle librerie da cui dipende la libreria .

— jdevlin
fonte

1

Grande! È esattamente quello che speravo. Non ho intenzione di utilizzare ampiamente C ++ 11, ma è bello sapere che potrei fare un pop in una funzione lambda o due nella mia implementazione nascosta quando è conveniente. Le analogie C e Java hanno un senso. Grazie.

— Konafa,

4

Sembra che tu voglia scrivere una nuova libreria che gli altri possano usare e che vorresti usare C + 11 come linguaggio di implementazione. Ci sono una serie di problemi da considerare:

introducendo una nuova versione di C ++ introdurrete la necessità di distribuire le nuove librerie di runtime C ++ con la vostra libreria, va bene?
si dovrebbe non utilizzare nuovi C + 11 tipi nell'interfaccia pubblica, altrimenti non sarà in grado di chiamarla.
In generale, dovresti evitare tipi complessi, come unique_ptr, anche vector, ecc. A meno che tu non stia distribuendo la tua libreria come codice sorgente, il layout degli oggetti nella tua libreria potrebbe differire dal layout nel codice client. Attenersi a tipi semplici che non presentano rischi di variazioni nella disposizione degli oggetti.

— Phillip Ngan
fonte