Newsgroup: it.comp.lang.c++
Titolo: Plugin

Devo realizzare un progetto che fa pesante uso di plug-in.
Cercando documentazione varia su consigli da seguire nella 
realizzazione di questo tipo di tecnologia mi sono imbattuto in questo 
link:
http://www.nuclex.org/articles/building-a-better-plugin-architecture
Che ne pensate?
Avete idee migliori da seguire o link a cui indirizzarmi?
Grazie

 Grazie
Ho anche trovato questo PDF molto ma molto allettante:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2015.pdf

Guglielmo Calligaro ha scritto:

I principi generali direi che sono quelli...
Se sei su windows, una buona scelta potrebbe essere quella di 
appoggiarsi a COM. Avresti il vantaggio di essere "indipendente" 
dall'ABI e adirittura dal linguaggio.
In pratica COM definisce ulteriori regole, restrizioni sul threading, 
meccanismi standard di comunicazione, ecc.. che (se rispettate) 
garantiscono la perfetta trasparenza.
Sono tutti dettagli che anche in un approccio "manuale" in c++ 
andrebbero comunque tenuti in considerazione...
COM fornisce anche una serie di "helpers" bell'epronti che volendo 
gestiscono un sacco di dettagli (trovare/caricare il componente, 
registrarlo, ecc...) (cerca su MSDN le funzioni che incominciano con 
Co... es. CoCreateInstance)
Lo svantaggio ï¿œ che COM ï¿œ un "concetto" veramente molto profondo e 
complesso e con una conoscenza superficiale si rischia di fare piccoli 
errori che magari sembrano a prima vista pure funzionare...

 appoggiarsi a COM. 
...
Dimenticavo la cosa piï¿œ importante:
uno dei problemi piï¿œ subdoli su cui probabilmente ti scontrerai ï¿œ la 
gestione della memoria dinamica.
Occorrono regole ben precise su chi ha la responsabilitï¿œ di 
allocare/deallocare e bisogna stare attenti a non mescolare gli heap.
Occhio che "librerie esterne" a volte usano lo heap...ragion per cui ï¿œ 
"pericoloso" far passare ad es. oggetti STL oltre il confine del 
modulo... (ma occhio anche alla libreria C...)
Naturalmente COM affronta anche questo tema.
(anche se qui esiste una regola d'oro che va quasi sempre bene: 
deallocare nello stesso modulo da cui si ï¿œ allocato)
HTH

> COM.
Se devo essere sinceri mi spaventa un po' COM.
Attualmente lo sto utilizzando perche' ho diversi moduli reallizzati 
come oggetti COM quindi posso dire di conoscerlo abbastanza bene.
Da quando Microsoft lo ha implementato mi aveva davvero entusiasmato e 
ho cercato di seguirne le varie evoluzioni.
Ma in questo progetto che voglio realizzare volevo fare un uso davvero 
pesante dei plug-in e ho paura che ne possano risentire le prestazioni 
oltre il fatto che volevo evitare di utilizzare il registry.
Pero' e' una buona idea da tenere in considerazione, visto che sono 
davvero nelle fasi preliminari ovviamente nulla di definitivo e' ancora 
stato deciso (o quasi).

 oltre il fatto che volevo evitare di utilizzare il registry.
Non credo che COM imponga per forza l'utilizzo del registry.
Ovvio che senza il reg diventa tutto un pelino + complicato, perchï¿œ mi 
sa che ti viene a mancare quello che la CoCreateInstance fa gratis (in 
particolare istanziare la factory).
Ma se vuoi, puoi sempre implementare il tuo meccanismo di factory 
personalizzato che non si appoggia al reg...
D'altra parte, se ci pensi bene, tutti questi dettagli di dritto e di 
rovescio ti troveresti comunque a doverli affrontare anche con una 
soluzione del tutto personalizzata.
IMHO l'unica cosa che ti puï¿œ dare in piï¿œ COM ï¿œ un insieme di regole 
"standard" che rendono "esplicite" tutte le possibili tematiche che 
necessariamente emergono quando si vogliono linkare dinamicamente in 
modo trasparente moduli binari