Ho una libreria condivisa scritta in C++. Esporta un'interfaccia visibile composta dalle funzioni extern "C" che creano, distruggono e manipolano i tipi opachi.Libreria condivisa C++ chiamata da C
Ora, mi piacerebbe avere un programma C puro che usi questa libreria.
Posso fare questo (piattaforma in modo indipendente)? Quando il runtime C++ e gli oggetti statici C++ verranno inizializzati se main non è scritto in C++?
La fase di inizializzazione dipende dalla piattaforma. Nel caso di Linux, le librerie caricate dinamicamente possono avere simboli appositamente dichiarati che vengono automaticamente chiamati da dlopen() quando la libreria viene caricata.
Vedere la pagina di manuale per dlopen(3), sezione I simboli obsoleti init() e fini() per ulteriori informazioni.
Gli inizializzatori statici sono implicitamente contrassegnati come __attribute__((constructor)), quindi in generale non è necessario fare nulla di speciale per chiamarli quando viene caricata la libreria condivisa. Sospetto che sia uguale o simile su altre piattaforme.
Posso fare questo (piattaforma in modo indipendente)?
Il caricamento della libreria è un'operazione dipendente dalla piattaforma.
Quando il runtime C++ e gli oggetti statici C++ vengono inizializzati se main non è scritto in C++?
Non importa. Saranno inizializzati prima che venga inserito il principale.
Bene, una libreria può ancora essere caricata (manualmente) dopo aver inserito 'main'. E "" Verranno inizializzati prima che il principale sia inserito ". È un equivoco. È definito dall'implementazione se l'inizializzazione di un oggetto statico si verifica prima che venga immesso "main" o in qualsiasi momento prima del suo primo utilizzo. Ma a tutti gli effetti pratici, sì, sono inizializzati prima di 'main', o subito dopo il caricamento della libreria. – jweyrich
In genere, i sistemi di librerie condivise dispongono di un proprio punto di accesso in cui eseguire questo lavoro, non main ma DLL hanno uno DLLMain in cui l'implementazione può inserire tale codice. Tuttavia, nel caso generale, non sono affari tuoi ed è il lavoro di qualsiasi compilatore usato per affrontare questo problema.
Addendum. (glibc :) init/fini è fornito dall'ambiente di runtime (crtS.o) e viene utilizzato per l'inizializzazione di oggetti di durata statica e funzioni di chiamata contrassegnate __attribute __ ((costruttore)), quindi l'esecuzione di init/fini da solo può causare problemi , incluso il salvataggio a causa di una doppia definizione di simbolo. –
@ jørgensen: Potrebbe essere il motivo per cui sono deprecati? – onitake