[C++] Come organizzare le dll

[ing82]

La domanda e' in merito a come organizzare le dll.
Cerco di spiegare con un esempio.
Diciamo che ho un file header che tratta Argomento1, quindi contiene le cassi che fanno riferimento a Argomento1.
Avendo racchiuso tutto quanto riguarda Argomento1 in un solo file header, potrei creare la libreria Argomento1.dll.
Ho poi un file header WidgetArgomento1, dove ci sono le classi che permettono all'utente di interagire mediante interfaccia grafica con le classi di Argomento1.
Potrei quindi creare WidgetArgomento1.dll, che pero' richiama Argomento1.dll, perche' ad esempio alcuni tipi enumerati che servono a WidgetArgomento1 sono definiti in Argomento1.
Prima domanda: ma quando creo WidgetArgomento1.dll, richiamo Argomento1.dll o creo un link statico a Argomento1.h (nel progetto per creare WidgetArgometo1.dll metto entrambi gli header, ma esporto solo le classi di WidgetArgomento1.dll)?

Il problema quindi e' come gestire le librerie, in previsione anche dei possibili aggiornamenti, ecc, qualche dritta, consiglio, materiale da consultare, ecc?

Grazie

[shodan]

Personalmente porrei classi interfaccia negli header file e le implementazioni nelle dll e userei le interfaccie come parametri. Viceversa crei problemi di dipendenza tra le dll (se ne aggiorni una, probabilmente dovrai aggiornare anche l'altra).

[MItaly]

Personalmente, o ci sono problemi specifici, o in genere linko tutto staticamente e bona. Quando aggiorni aggiorni tutto e sei sicuro che è tutta roba compatibile, senza dover pensare ai cambiamenti di ABI, ai clienti che si divertono a fare mix & match di dll di versioni diverse e altre bestialità di questo tipo.

[shodan]

ai clienti che si divertono a fare mix & match di dll di versioni diverse

Più che l'ABI è questo il problema, ma non credo sia difficilmente aggirabile.
Per l'ABI in se basta seguire i consigli riportati qui:
https://chadaustin.me/cppinterface.html

[MItaly]

Per l'ABI in se basta seguire i consigli riportati qui:

Sissì sono tutte cose note, ma (1) è una bella palla (soprattutto non avere oggetti STL sui boundary di interfaccia e stare sempre attenti con le allocazioni), e (2) è fragile, se non stai sempre attento rischi di scassare cose inavvertitamente. Se fai un bel binarione unico vivi tranquillo - se ha compilato sei ragionevolmente sicuro che non ci siano problemi di basso livello di quel tipo, e hai il vantaggio di un deployment banale.

La domanda che pongo a ing82 è: perché vuoi spezzettare il programma in più dll? Perché o hai dei vantaggi concreti in mente, o è solo una rottura di scatole.

[ing82]

La domanda che pongo a ing82 è: perché vuoi spezzettare il programma in più dll? Perché o hai dei vantaggi concreti in mente, o è solo una rottura di scatole.

Ringrazio per la domanda, che mi permette di cercare di chiarire il problema.

Premesso che programmo per me stesso, la mia attivita' vera e propria e' l'edilizia, ma faticando spesso a trovare il programma che fa quello che si vuole e come lo si vuole, mi sono rimboccato le maniche.
Ora, il problema e' che ad esempio il calcolo delle caratteristiche di una sezione, cosi' come l'inserimento dei suoi dati di input, ecc, sono cose che mi tornano utili in piu' situazioni/programmi.

Quindi, dopo aver creato ormai un po' di cose, ha iniziato a porsi il problema di come renderle riutilizzabili in altri programmi senza 'sforzi' da parte mia nel caso di aggiornamenti.

Ho quindi tentato di trasformare in dll alcune cose semplici, ma mi trovo proprio nella situazione descritta da Shodan, un richiamo continuo tra dll, che in caso di aggiornamento diventa una strage...

Viceversa crei problemi di dipendenza tra le dll (se ne aggiorni una, probabilmente dovrai aggiornare anche l'altra).

Il mio problema quindi, ancor piu' che le dll, e' forse ancora piu' banale e terra-terra.

Di avere un unico eseguibile che contiene tutto o che sia piu' piccolo e richiami le dll, a me sinceramente non ne frega niente, l'utente sono io, interessa molto di piu' capire come strutturare i progetti con l'ide che uso (QtCreator, se potesse essere utile, ma credo influenzi poco la risposta), in modo che se aggiungo ad esempio la possibilita' di impiegare un nuovo tipo di sezione che prima non c'era, questa cosa diventi disponibile a tutti i programmi che ne fanno uso senza dover impazzire io a ricordarmi dove questo e' da aggiornare.

Puo' aver senso a questo punto, al posto di copiare i file header e le rispettive implementazioni in ogni progetto, lasciarli in una cartella, e al momento dell'include, spedificare l'indirizzo in cui andare a cercarli? #include "C: ecc/header.h" ?

Spero di aver chiarito la mia richiesta, che mi rendo conto ora che rispetto a quanto prospettato nel titolo della discussione e' molto piu' terra-terra...

Grazie infinite

@Shodan:quanto proposto e' quello che qualcuno chiama D-pattern, o in modo simile? Per questa volta se posso scelgo una soluzione meno elegante sicuramente, ma che spero porti ad un risultato decente comunque. Grazie.

[shodan]

ma (1) è una bella palla (soprattutto non avere oggetti STL sui boundary di interfaccia e stare sempre attenti con le allocazioni)

Andiamo, in C la cosa è normale. In C++ convengo che la cosa è scomoda, ma non è la fine del mondo.

(2) è fragile, se non stai sempre attento rischi di scassare cose inavvertitamente.

In C++ vale per tutto, lo sai bene

[shodan]

Beh posto in questi termini la cosa è banale. Dipende però da quanto sai impostare il compilatore.
Nel mio caso ho creato nel filesystem una cartella, diciamo c:\shodan\include\hpp e l'ho inserita nel path di ricerca dei file include
in modo da scrive semplicemente
#include <hpp/primo.h>
#include <hpp/secondo.h>

poi ho creato una cartella c:\shodan\source
dove ho messo dentro tutti i sorgenti.

alla fine ho creato un file lib.cpp dove ho fatto gli include di tutti i .cpp della cartella
dopo aver testato che tutti i file.cpp della cartella compilassero singolarmente.

alla fine nel progetto inserisco lib.cpp
e nel resto dei file di progetto uso i miei header come sopra.

in questo modo condivido header e source files tra più progetti.

Comunque concordo con MItaly, le DLL danno parecchi grattacapi se si usano male.

[ing82]

Beh posto in questi termini la cosa è banale. Dipende però da quanto sai impostare il compilatore.

Non ho mai toccato niente del compilatore, quindi e' un campo inesplorato, ci proviamo...

.
Nel mio caso ho creato nel filesystem una cartella, diciamo c:\shodan\include\hpp e l'ho inserita nel path di ricerca dei file include
in modo da scrive semplicemente
#include <hpp/primo.h>
#include <hpp/secondo.h>

poi ho creato una cartella c:\shodan\source
dove ho messo dentro tutti i sorgenti.

Da perfetto ignorante posso permettermi questa domanda: perche' header e source non li tieni nella stessa cartella?

alla fine ho creato un file lib.cpp dove ho fatto gli include di tutti i .cpp della cartella

Perche' non hai fatto un lib.h con gli include di tutti i .h?

dopo aver testato che tutti i file.cpp della cartella compilassero singolarmente.

Ma anche senza controllarli singolarmente, che non saprei come fare, non me ne accorgo comunque durante la compilazione degli errori, e coi messaggi che da il compilatore capisco dove sta l'errore, e lo vado a correggere, o mi manca qualche pezzo?

alla fine nel progetto inserisco lib.cpp
e nel resto dei file di progetto uso i miei header come sopra.

Come sopra, perche' non lib.h?

Comunque concordo con MItaly, le DLL danno parecchi grattacapi se si usano male.

Ma quindi le dll, quando conviene usarle? quando una porzione del programma che si vuole realizzare e' 'a se stante' e viene richiamata per una durata limitata dell'esecuzione dello stesso? Quindi faccio una dll che tanto se l'aggiorno non va ad intaccare altro e ho il vantaggio di ottimizzare l'uso della memoria?
Grazie.

[ing82]

Beh posto in questi termini la cosa è banale. Dipende però da quanto sai impostare il compilatore.
Nel mio caso ho creato nel filesystem una cartella, diciamo c:\shodan\include\hpp e l'ho inserita nel path di ricerca dei file include

Ho provato ad aggiungere il percorso della cartella in cui ho inserito gli headers e i sources nella variabile d'ambiente PATH, ma ottengo errori, ma da quanto visto in giro mi sembra che non sia l'unica variabile da modificare, ma che lo stesso percorso debba essere aggiunto anche a LIB, INCLUDE, LIBPATH(variabili che io tra l'altro non ho nell'elenco) e TMP.

Mi sono fermato a PATH dato che ho una vaghissima idea di quello che sto facendo e non vorrei trovarmi a far danni.

La compilazione va a buon fine invece se mi disinteresso delle variabili d'ambiente e nel file di progetto aggiungo le variabili INCLUDEPATH e DEPENDPATH impostate con la cartella in questione, ma cosi' facendo, se cambio questo percorso mi ritrovo a dover aggiornare tutti i file di progetto, mentre con le variabili d'ambiente cambiata quella, credo che tutto vada a posto per tutti.

Uso QtCreator, con MinGW, che viene installato di default con QtCreator.

Grazie