[C++] Come organizzare le dll

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