Utilizzo della parola chiave export con i modelli

Come ho capito, è ansible utilizzare la parola chiave “export” in modo che sia ansible esporre classi di template o firme di funzioni attraverso un file di intestazione e astrarre l’implementazione effettiva in un file di libreria.
Qualcuno può fornire un pratico programma di esempio che mostra come farlo?
Ci sono degli svantaggi o punti importanti da notare durante l’utilizzo di questo?

EDIT: una domanda di follow-up basata sulle risposte. Come menzionato nelle risposte ‘export’ è deprecato in C ++ 0x e raramente supportato dai compilatori anche per C ++ 03x. Data questa situazione, in che modo si possono hide le implementazioni reali nei file lib e solo esporre dichiarazioni attraverso i file header, in modo che l’utente finale possa sapere quali sono le firme dell’API esposta ma non ha accesso al codice sorgente implementando lo stesso?

Prima di tutto: la maggior parte dei compilatori (inclusi gcc, Clang e Visual Studio) non supportano la parola chiave export .

È stato implementato in un unico front-end: il front-end EDG, e quindi solo i compilatori che lo utilizzano (Comeau e icc) supportano questa funzione. Il feedback degli implementatori di EDG è stato estremamente semplice: ci è voluto del tempo, è stato estremamente complicato, consigliamo di non implementarlo (1), di conseguenza è stato abbandonato in C ++ 0x.

Ora, lo standard consente (e questo è implementato almeno da gcc):

  • dichiarare una versione specializzata di una funzione modello in un’intestazione
  • per definire questa specializzazione in un singolo file sorgente

e farlo funzionare come ci si aspetterebbe da una funzione normale.

Nota: come indicato da Johannes in un commento, se una specializzazione completa di una funzione è definita in un’intestazione, deve essere contrassegnata come inline, altrimenti il ​​linker si lamenterà.

MODIFICARE:

(1) Finalmente trovato il mio riferimento Perché non possiamo permetterci l’esportazione (PDF) di Tom Plum, recensito da Steve Adamczyk, John Spicer e Daveed Vandevoorde di Edison Design Group che inizialmente lo implementò nel front-end di EDG.

L’esportazione è stata rimossa dallo standard C ++ . Non usarlo.

È difficile fornire un programma di esempio perché quasi nessun compilatore supporta l’esportazione. g ++ segnalerà un avvertimento dicendo che non è supportato, e IIRC non è nemmeno compilato in Visual Studio. Inoltre, l’esportazione è deprecata in C ++ 0x, il che significa che è improbabile che i futuri compilatori lo supporteranno del tutto.

Per una discussione su come utilizzare l’esportazione nelle poche compilazioni che lo supportano (vale a dire Comeau C ++), controlla questo link che spiega anche perché l’esportazione è difficile da implementare.

E ci scusiamo se questo si presenta come un grande sfogo anti-esportazione. Prometto che non odio l’esportazione! Non è ampiamente supportato e non si può davvero fare affidamento su di esso come programmatore.

Le ragioni per cui molti produttori di compilatori non lo supportano sono che, anche quando funziona, non funziona nel modo previsto dai programmatori.

Il miglior articolo che ho trovato sui problemi è qui:

http://msmvps.com/blogs/vandooren/archive/2008/09/24/c-keyword-of-the-day-export.aspx

Stai meglio istanziando i tuoi modelli.

Ho letto un articolo con il titolo qualcosa come Export non è supportato e non farebbe quello che vuoi comunque.

L’unico modo per fare ciò che vuoi è specializzarsi pienamente come è stato detto. Ma più di questo, se non riesci a vedere il codice sorgente di una libreria, non puoi compilarlo. Ciò significa che non è ansible accettare la memoria dynamic da esso poiché non è garantito che si utilizzerà l’eliminazione corrispondente al loro nuovo. Ad esempio, se il mio codice è il debug e la libreria è rilasciata, il deleter non corrisponderà al nuovo. Potresti usare shared_ptr e fornire un deleter, ma questo è TR1 e non ha esportazione.

C ++ 11 ora ha “modelli esterni” che sono già ben supportati dai moderni compilatori.