[C++] Come organizzare le dll

[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]

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.

[shodan]

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

Principalmente per una questione di ordine, poi perché ho degli header files che sono strettamente riservati ai source files senza che debbano essere visibili esternamente.

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

Per essere più modulare possibile e ridurre i tempi di compilazione.

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?

A volte mi basta aggiungere un solo source file, invece degli n-files raggruppati e tutto deve filare liscio comunque. Se usassi solo il file che li raggruppa tutti potrei creare delle interdipendeze tra i files. E' solo una questione di comodità. Nessuno ti vieta di scrivere un enorme file.cpp buttandoci dentro tutto il codice e aggiungendo man mano in coda.
La cosa veramente importante è inserire il file.cpp dentro il progetto (qualcosa del tipo add to project) e che il (o gli) header files siano visibili al compilatore.

...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.

Si potrebbe scrivere un intero capitolo sulla questione. A ogni modo le DLL si usano (in genere) quando applicativi, magari scritti in linguaggi diversi, devono usare lo stesso codice per qualcosa (che so, una libreria matematica iper ottimizzata con avx e multi threading). Oppure quando serve un applicativo modulare con poche interfacce e molte implementazioni, ma non serve che si le porti dietro tutte le implementazioni.
Oppure anche solo per sport (non occorre debba esserci sempre un motivo).
L'unica cosa da ricordare bene sempre è che una DLL ha regole molto più stringenti rispetto al codice sorgente nativo (e il link che ho messo ne riporta alcune).
Tra l'altro è possibile usare il caricamento on demand con le DLL, però è una cosa molto delicata da maneggiare.
Insomma se per le tue esigenze immediate non reputi necessaria una DLL, fanne a meno (magari sperimenta su altri progetti meno sensibili).

[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

[shodan]

ma cosi' facendo, se cambio questo percorso mi ritrovo a dover aggiornare tutti i file di progetto

E tu non cambiare percorso, no?

[ing82]

Capisco ora perche' la cosa e' banale, basta sapere che la variabile d'ambiente associata, e quindi da settare col percorso, e' CPLUS_INCLUDE_PATH, e il primo pezzo e' fatto.
Poi, per chi usa QtCreator e dovesse mai trovarsi nella medesima situazione, nel file di progetto, basta aggiungere i file .h e i file .cpp inserendo le seguenti righe, una per ciascun file .h e . cpp

HEADERS += $$(CPLUS_INCLUDE_PATH)/MyHeaders/pippo.h

SOURCES += $$(CPLUS_INCLUDE_PATH)/MySources/pippo.cpp

e tutto fila liscio, senza bisogno di aggiungere il file lib.cpp con gli include dei .cpp come spiegato in precedenza da shodan (altrimenti si ottengono una serie infinita di undefined reference to vtable, undefined reference to ::metaobject, ecc)

Il problema non e' tanto che prima o poi uno decidera' di cambiare il percorso della cartella, e' che lavora sulle stesse cose su due pc diversi, in cui per ragioni casuali le cose stanno in posti diversi, quindi riuscire a gestire il tutto con la sola variabile CPLUS_INCLUDE_PATH e' davvero tanta roba.

Se qualcuno si dovesse chiedere fino ad ora come ho fatto, in tutti i progetti avevo una copia dei file necessari, che in caso di modifica andavo a sovrascrivere ogni volta, ma non e' vita...

Grazie a tutti!

[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