Perché dovrei configurare un'interfaccia plugin in C++ invece di c

Question

Come risultato del mio previousquestions Mi sono chiesto: è utile impostare un'interfaccia C++ per un sistema di plugin? I seguenti punti parlano contro di essa:

• Nessun comune ABI tra i diversi compilatori e le loro versioni, nessun layout comune degli oggetti in memoria
• Nessun classe di esportazione diretta. Devi esportare fabbriche e distruttori. I problemi sorgono se gli oggetti sono trattenuti da altri oggetti che solo loro sono delete, ad esempio puntatori intelligenti.
• diverse implementazioni di STL, non si può passare un std::list<T> al plugin
• diverse versioni delle librerie utilizzate come Boost

Se vi trattenervi alle restanti parti del linguaggio C++ si quasi fine con il "sottoinsieme C". Ci sono dei punti che parlano dell'uso del C++? In che modo il Qt-Toolkit risolve i problemi citati?

Nota: Mi riferisco principalmente al sistema Linux. Tuttavia sono interessato a soluzioni su altre piattaforme.

Domanda aggiuntiva: quali sono i problemi che utilizzano un'interfaccia C? Il layout di memoria di struct s? Quali parti della lingua di C dovrebbero essere evitate?

Answer 1

Anche se questo è più sul "come" che sul "perché", potresti essere interessato alla libreria (not yet)Boost.Extension, così come allo author's blog sull'argomento.

Per il "perché" parte, i miei 2 (canadese) centesimi: dipende il pubblico (gli scrittori plugin) e sulla ricchezza dell'interfaccia tra l'applicazione ei suoi plugin:

• Se il il pubblico è grande o eterogeneo, le limitazioni di un sistema di plugin C++ (mantenendo il lato del plugin e il lato dell'app in sincronia rispetto alle versioni del compilatore e della libreria) diventano poco pratici e un'interfaccia C è più manutenibile. Se il pubblico è piccolo, omogeneo o sotto il tuo controllo, questi problemi non sono così significativi.
• Se l'interfaccia è ricca (mano che ondeggia sul significato preciso di "rich"), un'interfaccia C può essere scomoda da scrivere, e il bilanciamento si inclina sul lato C++.

Tuttavia, il primo criterio (il pubblico) è più importante e un'interfaccia C++ ha quindi senso solo se il pubblico è omogeneo e l'interfaccia beneficia in modo significativo dei guadagni espressivi.

Answer 2

Penso che tu stia rispondendo alla tua stessa domanda. Non c'è niente che ti impedisca di implementare una semplice interfaccia del plugin C e consentire ai produttori di plug-in di implementare il proprio plugin con C++. Basta provare e imparare dagli errori fatti dall'API Netscape Plugin ...

Answer 3

Generalmente è una buona idea scrivere interfacce su alcuni standard di interfaccia su cui è possibile fare affidamento. Ecco perché praticamente ogni SO fornisce una tale interfaccia. Sulla maggior parte degli Unix i compilatori C usano la stessa convenzione del sistema operativo, quindi chiamano la convenzione di chiamata C. Windows ha stdcall per questo scopo.

Se si tenta di utilizzare un'interfaccia di chiamata interna al compilatore, come quella di C++, si cadrà in preda a tutti i problemi menzionati. Anche gli aggiornamenti del compilatore sono suscettibili di affaticarti.

Answer 4

Una volta ho realizzato in C++ l'interfaccia del plugin per un sistema che ho sviluppato ed è stato un grosso errore. Fattibile, ma non pratico affatto. Oggi realizzerei sempre l'interfaccia esclusivamente in C e il più semplice possibile. I benefici di queste scelte sono davvero significativi. E se i tuoi programmatori di plugin desiderano un'API C++, puoi semplicemente scrivere un wrapper C++ che chiama l'interfaccia C.

Come bonus aggiuntivo, se i tuoi programmatori di plug-in desiderano un'API in qualsiasi altra lingua, per l'API C sarà sempre più facile creare collegamenti.