ho la mia soluzione per la mia applicazione istituito nel seguente modo - (sto usando Visual Studio e questo è un VC progetto ++)exe e dll condividere le stesse librerie statiche
NOTA: i progetti Blu sono compilati come librerie statiche.
come si può vedere, exe e dll condivide alcune delle librerie statiche (core.lib e utils.lib) e exe in-turn utilizza la DLL (tramite "load time dynamic linking" utilizzando la libreria di importazione).
la mia domanda è è una dipendenza corretta-installazione di avere? il problema che vedo è, quando questa applicazione è attiva e funzionante, ci sarà qualche codice duplicato nello spazio degli indirizzi del processo giusto? nel senso, tutte le funzioni che ci sono in Core.lib e Utils.lib appariranno due volte giusto? cos, Exe e DLL avranno questo codice compilato separatamente in loro.
in caso affermativo, un modo per risolvere il problema precedente è spostare il codice in esclusiva su dll o mantenere in exe e condividerlo (b/w exe e dll) tramite importazione/esportazione. ma ho molti oggetti di classe in core e utils e non mi piace l'idea di esportare/importare questi oggetti di classe (aggiungendo __declspec (dllimport/dllexport)) nei file di intestazione e inoltre potrei finire per aggiungere questo a molti dipendenti classe oggetti
questa è la mia comprensione e potrei sbagliarmi. si prega di suggerire correzioni e qual è il solito approccio seguito per affrontare tali problemi?
saluti,
Ho avuto questo "problema" e ho deciso che, finché il codice duplicato era relativamente piccolo, questo era accettabile. Se il codice duplicato è sostanziale, allora dovresti raggrupparlo come una libreria condivisa, invece ... ma poi potresti correre all'inferno della dipendenza se "Algo-DLL" si aspetta una versione diversa della libreria di "App". –